On Thu, Jul 30, 2020 at 10:58:20AM -0700, Greg Sims wrote:
> We are seeing: "has exceeded the maximum number of connections" in our
> logs for domains associated with outlook.com. We have a transport
> named "outlook:" in transport.regexp as follows:
>
> # outlook.com domains
> #
> /@outlook(\.[a-z]{2,3}){1,2}$/ outlook:
> /@hotmail(\.[a-z]{2,3}){1,2}$/ outlook:
> /@live(\.[a-z]{2,3}){1,2}$/ outlook:
> /@msn\.com$/ outlook:
Fine.
> main.cf is configured as follows:
>
> outlook_destination_concurrency_limit = 6
> outlook_destination_concurrency_failed_cohort_limit = 100
> outlook_destination_concurrency_positive_feedback = 1/3
> outlook_destination_concurrency_negative_feedback = 1/8
OK.
> This transport is configured as follows in master.cf:
>
> outlook unix - - n - 6 smtp
> -o syslog_name=outlook
Fine.
> We can control the number of "has exceeded the maximum number of
> connections" messages we see by limiting the number of processes in
> master.cf.
Sure.
> We would like to use Per-Destination Connection Caching to increase
> our throughput for "outlook:".
No, you *do not* want to do that. That can increase connection
concurrency beyond your process limit, in the form of idle connections
that have a different nexthop than the one to which you're currently
delivering email.
Instead, you want to *disable* even demand connection caching.
> Our mail server does not specify
> "relayhost =" in main.cf. Is it possible to associate per-destination
> caching with the "outlook:" transport? If not, what is the best
> alternative?
The question is moot. You DO NOT want to do this.
> smtp_connection_cache_destinations = hotmail.com, hotmail.es,
> hotmail.co.uk, outlook.com, outlook.es, live.com, msn.com
See above.
> should we try to include All the domains associated with "outlook:" so
> even small volume domains are not counted as connections by
> outlook.com servers? If this is the case, should/can we point
> "smtp_connection_cache_destinations =" to a regexp file?
You DO NOT want to cache connections. But you may want to route more
domains to this transport that you know are handled by Microsoft's
mail hosts.
The right solution is to get whitelisted by Microsoft, because you're
sending content their users want.
--
Viktor.
