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.
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?
Wietse
