Connected: An Internet Encyclopedia
5.3.2 Timeouts in SMTP

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1123
Up: 5. ELECTRONIC MAIL -- SMTP and RFC-822
Up: 5.3 SPECIFIC ISSUES
Prev: 5.3.1.2 Receiving strategy
Next: 5.3.3 Reliable Mail Receipt

5.3.2 Timeouts in SMTP

5.3.2 Timeouts in SMTP

There are two approaches to timeouts in the sender-SMTP: (a) limit the time for each SMTP command separately, or (b) limit the time for the entire SMTP dialogue for a single mail message. A sender-SMTP SHOULD use option (a), per-command timeouts. Timeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code.

DISCUSSION:

Timeouts are an essential feature of an SMTP implementation. If the timeouts are too long (or worse, there are no timeouts), Internet communication failures or software bugs in receiver-SMTP programs can tie up SMTP processes indefinitely. If the timeouts are too short, resources will be wasted with attempts that time out part way through message delivery.

If option (b) is used, the timeout has to be very large, e.g., an hour, to allow time to expand very large mailing lists. The timeout may also need to increase linearly with the size of the message, to account for the time to transmit a very large message. A large fixed timeout leads to two problems: a failure can still tie up the sender for a very long time, and very large messages may still spuriously time out (which is a wasteful failure!).

Using the recommended option (a), a timer is set for each SMTP command and for each buffer of the data transfer. The latter means that the overall timeout is inherently proportional to the size of the message.

Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:

A receiver-SMTP SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender.


Next: 5.3.3 Reliable Mail Receipt

Connected: An Internet Encyclopedia
5.3.2 Timeouts in SMTP