Greg Sims:
> > I suspect the real problem was that hundreds of domains were not
> > directed to the low-concurrency 'outlook' transport, and that
> > connection count 'overshoot' due to unused cached connections was
> > a red herring.
>
> Please recall that I collected 383 email domains into
> transport.outlook.regexp. I confirmed that all traffic going to
> outlook.com mx servers were going through the outlook: transport. I
This was after a bit of armtwisting from my end, and I recall this
was the first (and only) action that allowed you to significantly
increase the email volume.
> I have a set of outlook.com associated logs where (1) the outlook:
> transport was limited to 4 processes, (2) our email arrival rate was
> 500/minute and (3) outlook.com servers complained of MaxConnections.
> I would be glad to share this set of logs in hopes of answering the
> question: Is it rate limitations or connection limitations that causes
> outlook to issue MaxConnections? I can not share this log here due to
> size and the email addresses it contains. Please let me know if there
> is an email address I should send these logs to.
I decline. This thing has already cost way too much of my time.
> PS. I also have configured the following in main.cf:
>
> smtpd_recipient_restrictions = check_recipient_mx_access
> regexp:/etc/postfix/mx_access.regexp
>
> as a way to get all outlook.com traffic to flow thru the outlook:
> transport. More on this later.
This would avoid the need for hundreds of transport map entries,
and would avoid the need keep adding/removing entries as cusomers host
their email at outlook, or decide to take their business elsewhere.
Wietse
