On Wed, Feb 09, 2011 at 08:01:36PM -0500, Wietse Venema wrote:
> > This works fine for SMTP-over-TLS commands, as long as the sender
> > does not use overly-aggressive command pipelining; unfortunately
> > this approach is problematic for the DATA-over-TLS phase.
>
> The problem being that the "per SMTP line" time limits become "per
> TLS transaction" time limits. While SMTP plaintext is sent in small
> chunks of up to 1-2 kbytes, TLS transactions can be as large as 16
> kbytes, and an entire TLS transaction must be received before the
> plaintext can be made available to the application.
>
> This is only a problem when time limits are set really short with
> Postfix SMTP server stress mode, and connections are slower than
> 1 kbyte/s or so. The Postfix SMTP client sends chunks of up to 4
> kbytes over ethernet-like networks which makes the problem with
> large transactions less of an issue.
With the default stress-dependent timeout of 10s, indeed each SSL_read()
needs to succeed in under 10s, so senders that:
- Actually use maximum-sized 16k buffers above the SSL_write()
layer.
- Have trouble delivering 128Kbits in 10s.
may get dropped under stress conditions. Now 12.8 Kbps is a very modest
bandwidth these days, and is only the limit under stress conditions, I
don't think we need to worry too much about setting the bar this high.
Receiving systems that have clients that need a bit of extra help can
raise the stress timeout...
> It seems that the best approach here is to try the new per-transaction
> time limit as the default mechanism during the Postfix 2.9 development
> cycle, with the option to use the traditional per-read and per-write
> time limit where interoperability over slow connections is more
> important than availability.
Do we really need a switch, or can we just document raising the stress
timeout as the work-around?
--
Viktor.
