Read timeouts

Timeouts all have option names Timeout.suboption. The recognized suboptions, their default values, and the minimum values allowed by RFC 1123 section 5.3.2 are:

The time to wait for an SMTP connection to open (the connect(2) system call) [0, unspecified]. If zero, uses the kernel default. In no case can this option extend the timeout longer than the kernel provides, but it can shorten it. This is to get around kernels that provide an absurdly long connection timeout (90 minutes in one case).
The wait for the initial 220 greeting message [5m, 5m].
The wait for a reply from a HELO or EHLO command [5m, unspecified]. This may require a host name lookup, so five minutes is probably a reasonable minimum.
The wait for a reply from a MAIL command [10m, 5m].
The wait for a reply from a RCPT command [1h, 5m]. This should be long because it could be pointing at a list that takes a long time to expand (see below).
The wait for a reply from a DATA command [5m, 2m].
The wait for reading a data block (that is, the body of the message). [1h, 3m]. This should be long because it also applies to programs piping input to sendmail which have no guarantee of promptness.
The wait for a reply from the dot terminating a message. [1h, 10m]. If this is shorter than the time actually needed for the receiver to deliver the message, duplicates will be generated. This is discussed in RFC 1047.
The wait for a reply from a RSET command [5m, unspecified].
The wait for a reply from a QUIT command [2m, unspecified].
The wait for a reply from miscellaneous (but short) commands such as NOOP (no-operation) and VERB (go into verbose mode). [2m, unspecified].
In server SMTP, the time to wait for another command. [1h, 5m].
The timeout waiting for a reply to an IDENT query [30s[11], unspecified].

For compatibility with old configuration files, if no suboption is specified, all the timeouts marked with * are set to the indicated value.

Many of the RFC 1123 minimum values may well be too short. Sendmail was designed to the RFC 822 protocols, which did not specify read timeouts; hence, versions of sendmail prior to version 8.1 did not guarantee to reply to messages promptly. In particular, a RCPT command specifying a mailing list will expand and verify the entire list; a large list on a slow system may easily take more than five minutes[12]. I recommend a one hour timeout -- since a communications failure during the RCPT phase is rare, a long timeout is not onerous and may ultimately help reduce network load and duplicated messages.

For example, the lines:

O Timeout.command=25m
O Timeout.datablock=3h
sets the server SMTP command timeout to 25 minutes and the input data block timeout to three hours.

[Contents] [Previous] [Next]

Questions or problems regarding this web site should be directed to Steve Gielda.
Copyright 1999  All rights reserved.
Last modified: Friday April 02, 1999.