On Mon, Dec 31, 2012 at 02:05:38PM -0500, Wietse Venema wrote: > Marcin Owsiany: > > Wietse Venema <wietse <at> porcupine.org> writes: > > > It is not a major effort to give those cache entries a finite > > > time-to-live but this needs a better justification that what appears > > > to be an attempt to circumvent Yahoo rate limits. > > > > I have a need similar to the original poster. In my case the use case > > is to gradually move outgoing traffic to a new egress IP. > > > > I have separate transports set up in master.cf per address like this: > > > > smtp unix - - - - - smtp > > out1 unix - - - - 50 smtp \ > > -o smtp_bind_address=10.150.15.101 > > out2 unix - - - - 50 smtp \ > > -o smtp_bind_address=10.150.15.102 > > [...] > > > > and additionally the senders are partitioned across IPs > > with sender_dependent_default_transport_maps > > > > Moving a big chunk of traffic in one go to a new IP that was never > > sending any traffic before will just cause it to get greylisted > > or blocked altogether. > > > > Given I have a low number of high-volume senders, I cannot find > > an easy way to start sending (say) 1% of given sender's traffic > > from a new IP. Any suggestions? > > You did not provide enough context to figure out what Postfix caching > feature you're referring to, so I will assume that this is the > one-element reply cache with transport map lookups.
Gmane nagged me to remove excessive citation, and I guess it got too terse. > In that case the obvious solution is not to send 100% of all email > to the same destination domain. That will flush the one-element > cache frequently, and force fresh transport map lookups. > > What is the business use case to send 100% of all email to the same > destination domain? That's not what is happening. Let me explain a bit more: There's a dozen or so envelope-senders (distribution lists), each periodically sends to a lot of recipients (few thousand to a few dozen thousand). The recipients are distributed over what I think is a typical country-wide sample of domains, which inevitably means the few big webmail services get a large portion. In the basic case, sender_dependent_default_transport_maps assigns each sender to one outgoing IP address, to try and limit colateral damage if one of them screws up and gets blacklisted. I imagine this might sound like a spam sending service, but it's not :-) Now the problem is when we want to move a sender to a different IP address. Because receivers don't like a previously-idle IP to suddenly start sending lots of mail, we need to start with a trickle, to build reputation. Ideally the smtp daemon would be able to bind to a few addresses and there would be an option to assign egress traffic split between them. However I did not find anything like that, so my next idea was to use a custom randomized "tcp" sender_dependent_default_transport_maps lookup table that would map "sender1" to, say, "out1" in 99% of cases and "out2" in the remaining 1%. However the builtin caching would defeat that. regards, -- Marcin Owsiany <[email protected]> http://marcin.owsiany.pl/ GnuPG: 2048R/02F946FC 35E9 1344 9F77 5F43 13DD 6423 DBF4 80C6 02F9 46FC "Every program in development at MIT expands until it can read mail." -- Unknown
