> On Mar 18, 2018, at 1:55 PM, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
>
>> * Caching open TLS connections in the smtp(8) delivery agent for
>> reuse by scheduling repeated deliveries to the same delivery
>> agent runs into complex scheduling difficulties. The presence
>> of open connections don't, and should not IMHO alter scheduler
>> priority. Messages should still leave in approximately FIFO
>> order (subject to (n)qmgr's periodic preemption of messages that
>> split into many envelopes).
>
> I believe routing multiple messages for the same destination through an
> array of currently open connections (held by different processes) should
> not be slower than opening new connection for each message.
>
>> This would be a rather non-trivial effort. And downstream MTAs
>> at major providers seem to frown on connection re-use these days.
>
> is there an evidence about this?
>
>> While traffic to smaller destinations is typically less
>> performance-critical. So while having TLS connection caching
>> would be nice, it is not clear that it is a high priority given
>> the high cost and possibly only moderate benefit.
>
> that is imho still the question. But I'm more curious about questions above
Sorry, no cycles to dissect this point by point. My view is as stated in
the previous message:
* I believe that support for this requires proxy processes to handle TLS
on behalf of (multiple) SMTP delivery agents. The connection cache
would then hold a connection to the proxy, rather than a connection to
the remote destination.
* The feature is attractive, but not urgently compelling. It is complex
to implement, so I cannot predict when work in that direction might begin.
--
Viktor.
