Greg Sims:
> > > I looked for domains that *are not* using the outlook: transport but
> > > are using the outlook.com relay servers. There are 383 such domains
> > > -- the vast majority are one email address per domain. These domains
> > > are competing for the limited number of outlook.com connections and
> > > they are not being controlled by the outlook: transport process limit
> > > in master.cf. Adding 383 domains to outlook: in transport.regexp
> > > seems a bit extreme and would be impossible to maintain. How can we
> > > control the number of connections made on behalf of this set of
> > > domains to the outlook.com relay servers?
> >
> > With automated logfile analysis, such domains could be added to a
> > transport map. Once a map is populated there will be a trickle of
> > updates.
>
> I created transport.outlook.regexp which contains the 383 domains
> mentioned above. I also added the following in main.cf:
>
> transport_maps = regexp:/etc/postfix/transport.regexp,
> regexp:/etc/postfix/transport.outlook.regexp
I suppose that the trick to autmically group deliveries with
check_recipient_mx_access was not feasible. That's fine, I will
toss it into a new advanced Postfix configuration page, together
with some other advanced solutions.
> What is the relationship between the number of processes for outlook:
> transport in master.cf and the number of simultaneous connections that
> can be made to the outlook.com servers?
The number of simultanous connections equals a) the number of used
connections (one per SMTP client) plus b) the number of unused
connections waiting in the connection cache. The number a) is the
number of processes in master.cf, while the number b) varies with
the number of high-traffic destinations.
With current Postfix versions there is no way to control b), except
for making it zero by turning off connection reuse. That is unfortunate
because connection reuse has helped to improve delivery performance
for plaintext and for TLS-encrypted connections.
I proposed a simple way to keep the sum of used+unused connections
<= the process limit: when a connection can't immediately be reused,
purge some connection from the connection cache and create a new
connection. That will require new code (a new RPC from the SMTP
client to the connection cache service), and can be available in
Postfix 3.6 and later.
> I changed master.cf to 3 processes for outlook: in hopes of reducing
> MaxConnections feedback -- I can not go much smaller.
This has been asked before: when Outlook puts you in the penalty
box and starts ratelimiting your new connections, was that because
a) you exceeded a limit for the number of SIMULTANEOUS CONNECTIONS,
or b) you exceeded a limit for the number of NEW CONNECTIONS over
a time interval.
I am asking because these two scenarios have different solutions,
and three is awfully low.
Wietse
