Wietse Venema:
> With Postfix 2.9 I'm hardening the Postfix SMTP server and client
> implementations against exhaustion problems with byte-at-a-time
> I/O, by enforcing a total time limit per SMTP line, instead of a
> time limit per read(2) or write(2) system call.
...
> I'm now adding similar deadline support to the Postfix TLS engine.
> Below is a patch that naively implements read/write timeouts by
> taking the per-line time limits for plaintext mail, and using the
> same limits for TLS transactions.
>
> 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.
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.
My Postfix hacking time is used up for much of this year, so I'll
document the above and roll out a snapshot release based on the
patch that I circulated the other day.
Wietse
