On Mon, Jul 07, 2014 at 08:38:02PM -0400, James Cloos wrote:

> VD> What sort of limit did you have in mind.  The default is 20 per
> VD> nexthop domain (per recipient when the transports recipient
> VD> concurrency is 1).  Split randomly across the domain's MX hosts.
> VD> This is unlikely to be a problem.
> 
> One or two sockets per MX.

Postfix has no per-MX concurrency limits,  only per-destination
limits, which split across the MX hosts somewhat randomly.  At times
some MX hosts may see more than their "fair" share of connections. 
Subject to the usual statistical considerations.

> VD> If you set the concurrency limit to equal the MX host count, you
> VD> get roughly this on average, but each message is delivered over a
> VD> separate connection, and the connection distribution is random,
> VD> not round-robin.
> 
> That is exactly what I attempted with the below configs.
> 
> >> smtp_destination_concurrency_limit = 2
> >> smtp_connection_cache_destinations = jhcloos.com

These settings require a "postfix reload" to update the queue
manager configuration.

The cache setting is irrelevant given TLS support.  The concurrency
limit is however enforced, per nexthop destination.  Note, that
when a single MX host supports multiple MX domains, it will see
that many connections per domain.

Without detailed log analysis, and relevant transport configuration
details, your anecdotal observations with netstat are not useful.

> VD> No, but TLS and connection caching are mutually exclusive (for
> VD> destinations that support STARTTLS, non-TLS destinations are still
> VD> cached).
> 
> Any chance of changing that in future versions?

Not likely in 2.12, this is a difficult problem.

> There should be no reason to have to use separate connections per
> message just because tls is used.

Migrating SSL encrypted connections between processes is rather
difficult.  We'd need a reverse TLS proxy in Postfix that handles
multiple outgoing TLS sessions in a single process, and mechanisms
to push per-connection policy to the proxy and query the resulting
security state.  I don't see this happening in 2.12.

-- 
        Viktor.

Reply via email to