On Fri, Jan 18, 2013 at 09:49:34AM -0800, Steve Jenkins wrote:
> Agreed - but Yahoo is really the only one we're having issues with (even
> after complying with all their guidelines here):
>
> http://help.yahoo.com/kb/index?page=content&y=PROD_MAIL_ML&locale=en_US&id=SLN3435
>
Yes, they are willing to cripple SMTP and expect everyone to cope,
because they are too big to ignore. :-)
Rumour has it that established proffesional bulk-senders typically
don't turn up new IP addresses (no existing good reputation) to
full capacity overnight. Rather, their sending software gradually
ramps-up load to a new address allowing its reputation to build-up
over time (the first few weeks may be at a low load, then add more,
...).
Once your IP reputation is good, you should be able to use reasonable
concurrency... You may want disable the demand connection cache
for Yahoo. This cache is primarily useful for destinations that
sporadically have some of their MX records unreachable at the TCP
layer.
Yahoo's MX SMTP pool essentially never has an IP address that is
completely down. Instead, you can set a low "smtp_connect_timeout",
just in case.
master.cf:
yahoo unix - - n - - smtp
-o smtp_connect_timeout=$yahoo_connect_timeout
-o smtp_connection_cache_on_demand=$yahoo_connection_cache_on_demand
main.cf:
# Good enough for light RTT to the moon
yahoo_connect_timeout=3s
# Don't annoy them with connection reuse.
yahoo_connection_cache_on_demand=no
At that point you may not even need rate delays, just set a modest
concurrency, and typical SMTP transaction latency of 0.2-0.5s (
with spam checks, RBL lookups, ...) will give you at most 2-5
messages per unit concurrency per second.
--
Viktor.
