> > 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.
I updated master.cf based on your recommendation:
outlook unix - - n - 6 smtp
-o syslog_name=outlook
-o smtp_connection_cache_on_demand=no
We have our ip addresses signed up for both SNDS and JMRP. Are there
additional white list strategies for Microsoft?
Turning off connection caching is not intuitive from reading the
CONNECTION_CACHE_README which says:
SMTP Connection caching can also help with receivers that impose rate
limits on new connections.
and suggests:
smtp_connection_cache_destinations = hotmail.com, ...
Perhaps I wanted the connection cache to be the solution for "has
exceeded the maximum number of connections" when I read the README.
Thanks, Greg
www.RayStedman.org
On Thu, Jul 30, 2020 at 3:52 PM Viktor Dukhovni
<postfix-us...@dukhovni.org> wrote:
>
> 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.
