On Wed, Feb 27, 2013 at 01:45:04PM +0000, Thorsten Glaser wrote: > > deliveries. Proper SMTP connection caching is not done by the SMTP > > clients but by a separate process that is queried by SMTP clients. > > If you don't manage to do that with TLS, this statement is plainly wrong.
If you don't understand what you're talking about, you're liable to say things that are plainly wrong. > Connection caching is a matter of also being nice to the recipient, who > doesn't have to spawn many sendmail processes in parallel to handle the > roughly 500 mails that piled up on the Postfix side, right now. No, connection caching has nothing to do with concurrency. Whether connections are cached, or not, Postfix will attempt parallel delivery up to the configured concurrency limit: http://www.postfix.org/postconf.5.html#transport_destination_concurrency_limit http://www.postfix.org/postconf.5.html#smtp_destination_concurrency_limit http://www.postfix.org/postconf.5.html#relay_destination_concurrency_limit ... Connection caching is a latency reduction optimization on the SMTP client to reduce the impact of TCP connect timeouts when a subset of the MX hosts for a destination is unreachable. The load on the remote server is identical with and without connection caching. > If Postfix were able to do proper connection reuse (WITH TLS, of course!) > the mail delivery wouldn't stop after the first couple of messages was > submitted (because sendmail stops listening when the load reaches 8) Don't blame Sendmail design flaws on Postfix. The "RefuseLA" and "QueueLA" features are fundamentally broken. Set these sufficiently high that you never hit these in practice, an MTA should never suspend delivery under high load, that just leads to even higher load later. Sendmail lacks a queue-manager, if you really want to avoid Sendmail melt-downs under load, deploy Postfix. > So I request of Postfix to implement connection reuse, supporting TLS > (that means with*out* the separate d?mon unless you manage to be able > to do that and still use TLS), by default. Connection caching without the ability to re-use the connection in a different delivery-agent process *is* abusive of the remote system, since you're keeping a remote process occupied and idle, while making new connections. This will not be implemented. Migrating TLS sessions between processes is non-trivial due to understandablel limitations in the OpenSSL API (it is not easy to completely serialize the cryptographic state of an established SSL connection). > Thanks. > > Sorry for my tone, I'm a tad disgruntled right now *and* under pressure > from my cow-orkers to get the pile of mails delivered. When disgruntled, especially due to problems with system "A", don't rant on the mailing list for system "B". -- Viktor.
