> On Mar 15, 2018, at 10:38 AM, Karol Augustin <ka...@augustin.pl> wrote:
>
> I think what Matus is asking here is the RSET implementation in postfix
> client. For example I have software that send some automated e-mail over
> night using single SMTP connection (written in perl). After each e-mail
> it does $smtp->reset(); and than delivers next e-mail using the same
> connection. Final effect looks like that:
>
> disconnect from localhost[127.0.0.1]:51596 ehlo=1 mail=63 rcpt=71
> data=63 rset=63 quit=1 commands=262
>
> I believe Matus is asking if that could be implemented in postfix so it
> connects to remote SMTP server and delivers one e-mail after another
> issuing RSET after each one and not disconnecting.
Yes, this much is clear, but the architectural constraints are difficult.
* Live SSL connections (rather than cached sessions) cannot be migrated
across processes.
* SMTP STARTTLS does not have a STOPTLS counterpart that would allow
the connection state to return to cleartext with TLS resumption on
re-use. This could be introduced, but would take many years to be
implemented on some non-trivial fraction of servers.
* Using TLS proxy processes for outbound TLS connections requires
complex new code and increases the Postfix memory footprint, and
may reduce throughput under load (when all the destination's MX
hosts are up and accept connections quickly).
* 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).
Given the above the least bad is IMHO the proxy approach, with all
TLS processing in a pool of outbound TLS proxy processes, with the
cached connections being cleartext from the delivery agent to the
proxy.
This would be a rather non-trivial effort. And downstream MTAs
at major providers seem to frown on connection re-use these days.
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.
--
Viktor.
