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.
Actually no - I don't see any reason to use RSET, unless a problem appears.
Is it needed without error appearing?
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.
On 15.03.18 11:01, Viktor Dukhovni wrote:
Yes, this much is clear, but the architectural constraints are difficult.
* Live SSL connections (rather than cached sessions) cannot be migrated
across processes.
This is precisely why I asked, if this can be done within one process -
no interprocess migration needed.
If a single smtp process (that alread did the TLS handshake) could deliver
multiple mail, when there is mail in queue for the same destination.
This could give us performance advantage in cases when there are more mails
in the queue than our smtp_destination_concurrency_limit.
It could be faster in case of SMTP destination refusing connections over
its limit, when our smtp_destination_concurrency_limit is not full yet
(and thus postfix tries to open new connections that are refused and mail is
delayed).
It would also help in case of unreachable servers - if SMTP client found
working server for a destination, it could pass multiple mail to it.
* 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).
This is just what am I asking for - how much of new code or complexity it
requires.
I have no knowledge of postfix stycture and the docs at
http://www.postfix.org/OVERVIEW.html#delivering
don't explain it in detail.
so I can only ask and speculate..
* 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
:-)
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Save the whales. Collect the whole set.
