>>>>> "VD" == Viktor Dukhovni <[email protected]> writes:
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.
>> Each subset of messages has a different +extension in the localpart.
VD> This would only matter if you set the transport's recipient
VD> concurrency to 1. Then mail is queued by recipient, rather than
VD> by domain.
That was my impression, but just in case I read it wrong it seemed
useful to note the fact.
>> 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.
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
VD> TLS and connection caching are mutually exclusive.
>> but still get as many Verified TLS connection established messages in
>> the logs as status=sent lines.
VD> See above. However, at most two delivery agents have open connections
VD> at any time with the above settings.
I got more than that. The vendor saw more than a dozen concurrent
outgoings before I added the above two configs. Which was a problem,
until I explained that I was only sending to myself.
And while testing, I saw more ESTABLISHED at a time, too. Even after
adding the above two lines.
>> Do any of:
>>
>> smtp_use_tls=yes
>> smtp_enforce_tls=yes
VD> These are obsolete, and should be removed from main.cf. They are
VD> only used when smtp_tls_security_level is empty.
Cool.
>> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
>> smtp_tls_security_level = dane
VD> This turns on opportunistic DANE TLS.
Intentionally. I like using that better than smtp_tls_policy_maps,
given that I publish tlsa for my MXs.
>> smtp_tls_note_starttls_offer = yes
VD> This is not needed when TLS is on by default.
Like the use_tls, it was copied from old configs which have been
incrementally updated.
>> interfere with concurrency limits?
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?
There should be no reason to have to use separate connections per
message just because tls is used.
-JimC
--
James Cloos <[email protected]> OpenPGP: 0x997A9F17ED7DAEA6
