Skip to content

What Timeouts Should I Use In Mail Server To Get Email Through Traffic Control?

By Ken Simpson | 3 minute read

As our customer base grows, we are increasingly coming into contact with email marketers who want to know how they should configure their outbound mail servers in such a way that they can still deliver email across a traffic shaped connection. I thought it would be useful to put together a brief post instructing ESPs on the SMTP timeouts, which Traffic Control is designed to respect so that all legitimate senders have a chance to get their email delivered.

RFC 5321 (the successor to RFC 2821 and RFC 821) very clearly defines the timeouts that mail servers should respect. Here’s the relevant text from the standard:  Timeouts

An SMTP client MUST provide a timeout mechanism. It MUST use per-
command timeouts rather than somehow trying to time the entire mail
transaction. Timeouts SHOULD be easily reconfigurable, preferably
without recompiling the SMTP code. To implement this, 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: Initial 220 Message: 5 Minutes

An SMTP client process needs to distinguish between a failed TCP
connection and a delay in receiving the initial 220 greeting message.
Many SMTP servers accept a TCP connection but delay delivery of the
220 message until their system load permits more mail to be
processed. MAIL Command: 5 Minutes RCPT Command: 5 Minutes

A longer timeout is required if processing of mailing lists and
aliases is not deferred until after the message was accepted. DATA Initiation: 2 Minutes

This is while awaiting the "354 Start Input" reply to a DATA command. Data Block: 3 Minutes

This is while awaiting the completion of each TCP SEND call
transmitting a chunk of data. DATA Termination: 10 Minutes.

This is while awaiting the "250 OK" reply. When the receiver gets
the final period terminating the message data, it typically performs
processing to deliver the message to a user mailbox. A spurious
timeout at this point would be very wasteful and would typically
result in delivery of multiple copies of the message, since it has
been successfully sent and the server has accepted responsibility for
delivery. See Section 6.1 for additional discussion. Server Timeout: 5 Minutes.

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

The most common problem we see with email marketers is that their mail servers fail to wait at least three minutes for each DATA send operation to complete. Probably the second most common problem is senders who seem to set an arbitrary timeout on the delivery of the entire message.

Whatever you do as an email sender, it’s important to respect the RFCs if you want to get your mail delivered reliably – including formerly esoteric parts such as the timeout requirements.

Cut your support tickets and make customers happier