On Mon, Jul 07, 2014 at 06:17:05PM -0400, James Cloos wrote:
> It can generate a large number of mails in a short time, so I'm trying
> to limit how many concurrent sockets pf on that box opens with my MXs.
What sort of limit did you have in mind. The default is 20 per
nexthop domain (per recipient when the transports recipient
concurrency is 1). Split randomly across the domain's MX hosts.
This is unlikely to be a problem.
> Each subset of messages has a different +extension in the localpart.
This would only matter if you set the transport's recipient
concurrency to 1. Then mail is queued by recipient, rather than
by domain.
> Ideally, I'd like it to open one to each of the equal-priority MXs,
> starttls with each, and dump the mails between them until the queue
> drains.
If you set the concurrency limit to equal the MX host count, you
get roughly this on average, but each message is delivered over a
separate connection, and the connection distribution is random,
not round-robin.
> I tried setting:
>
> smtp_destination_concurrency_limit = 2
> smtp_connection_cache_destinations = jhcloos.com
TLS and connection caching are mutually exclusive.
> but still get as many Verified TLS connection established messages in
> the logs as status=sent lines.
See above. However, at most two delivery agents have open connections
at any time with the above settings.
> Do any of:
>
> smtp_use_tls=yes
> smtp_enforce_tls=yes
These are obsolete, and should be removed from main.cf. They are
only used when smtp_tls_security_level is empty.
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_tls_security_level = dane
This turns on opportunistic DANE TLS.
> smtp_tls_note_starttls_offer = yes
This is not needed when TLS is on by default.
> interfere with concurrency limits?
No, but TLS and connection caching are mutually exclusive (for destinations
that support STARTTLS, non-TLS destinations are still cached).
--
Viktor.
