OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: feature request: timeouts in smtpd

From: Wietse Venema (wietseporcupine.org)
Date: Thu Feb 01 2007 - 12:46:43 CST


Victor Duchovni:
> It is appealing to propose a feature to control "connection hogging"
> and implement a lower limit after "." and "RSET" and before the start
> of the next mail transaction.
>
> To make this completely correct, and also enforce a low limit for "NOOP"
> and other junk commands after the transaction, it makes more sense to
> define this lower limit as applying to all commands that are not part of
> a delivery transaction, i.e. those are not after "MAIL" or that are after
> "." and before the next "MAIL".
>
> # Timeout outside an SMTP transaction:
> #
> # Backwards compatible default, anything much smaller than 30s is
> # probably aggressive, and would need extensive field testing:
> #
> smtpd_idle_timeout = 300s
>
> # Timeout during an SMTP transaction:
> #
> smtpd_timeout = 300s

Since we're changing parameter behavior maybe we can change the
parameter name as well. This way we can preserve compatibility.
It's also easier to say that feature X exists in release Y, than
saying that feature X does A or B depending on the release you're
using.

        # The default from way back when.
        smtpd_timeout = 300s

        # Split for finer control over connection hogging.
        smtpd_idle_timeout = $smtpd_timeout
        smtpd_mail_timeout = $smtpd_timeout

> The $smtpd_idle_timeout would apply until "MAIL" is received, at which
> point the timeout would be changed to "$smtpd_timeout". The timeout would
> be set back to $smtpd_idle_timeout when the server:
>
> - Sends a "." response.
> - Responds to a command that resets the mail transaction
> (RSET, EHLO, HELO, but not "STARTTLS", because we already
> have a separate smtpd_starttls_timeout).
> - Rejects the "DATA" command.
>
> Would this meet your needs? How short a timeout are you considering and
> why?

Does the poster understand that Postfix's time limits are not
limiting the total duration of the DATA command, but rather, the
time for each individual read/write operation?

        Wietse