Keep Your SMTP Mail Flowing

I'm slowly unpacking after my recent move, gradually discovering which boxes the various pieces of my office ended up in. One thing I haven't needed to worry about is the flow of SMTP email to and from my Exchange 2000 Server system. A few simple steps and a bit of planning ensured uninterrupted email flow.

You're probably familiar with the basic process that an SMTP server uses to find the correct server for a particular recipient. When a server prepares to send an email message to a nonlocal recipient, the sending server needs a way to find out which server to connect to. The DNS MX record provides this information. You can register one or more MX records for a particular domain. Each MX record specifies the DNS Fully Qualified Domain Name (FQDN) or IP address of a mail server that should receive email for a particular domain. For example, contoso.com might have an MX record that reads

contoso.com MX 10 mail.contoso.com

This MX record says that any email for a recipient in the contoso.com domain should go to the host mail.contoso.com. The 10 is a preference value. You can specify multiple MX records; the sending SMTP server first tries the record with the lowest preference value. If that connection fails—for example, when the specified server is unavailable—the sending server automatically tries the server with the next-lowest preference value and so on. If more than one MX record has the same preference value, the DNS server chooses one MX record and sends the MX records to the sending server in round-robin order. This process provides a degree of load balancing for inbound email.

You can exploit the ability to specify multiple MX records to keep email moving when a host is down. By specifying additional MX records, you can ensure that a host is always available to accept email. Most ISPs offer this service, commonly known as SMTP queuing; if your ISP doesn't, you can probably find a local business, government agency, or school that's willing to swap queuing services with you (i.e., create and maintain MX records for you if you do so for it). Just make sure that the queuing server's MX record has a higher preference than your primary SMTP server's MX records.

"But wait," you might be thinking. "How do I get my email from the queuing server?" Good question. The simplest way is to let the queuing server contact your server as part of the normal SMTP retry process. For example, most UNIX mail servers have a default retry interval of 15 or 30 minutes, so a UNIX queuing server will typically try to send you queued mail at those intervals. However, this process might not work for you, particularly if you use an on-demand connection. Instead, you can create an SMTP connector, point it to the queuing server, and set the connector to use the SMTP ETRN or TURN command to dequeue your email.

These two SMTP commands are similar, except that ETRN has better security and is more powerful (see Internet Engineering Task Force—IETF—Request for Comments—RFC—1985, available at the first URL below, for complete details of ETRN's features). Both commands tell the queuing server, "I am the mail server for the specified domain. Please send me my email now." For example, when the contoso.com Exchange 2000 server connects to the Internet, the server can establish an SMTP connection to mail.fabrikam.com and use the command ETRN contoso.com to initiate email retrieval. Exchange Server 5.5 and later support ETRN and TURN. (For more information about SMTP dequeuing, see the excellent FAQ that Simpler-Webb maintains at the second URL below.)

Now that I know my SMTP email will continue to arrive at my Exchange 2000 server, I'm free to worry about more important things. Now, where did I put that wireless base station?

IETF RFC 1985

Simpler-Webb Exchange-Dequeue FAQ