Understanding Relaying

SMTP relaying is like antibiotics. When used properly, it can be extremely helpful. When used improperly, it can cause a great deal of woe. Microsoft Exchange is flexible when it comes to relaying configuration, but before you can configure it you should understand what relaying is and when it should and shouldn’t be used.

Understanding SMTP Store-and-Forward Protocol

SMTP is designed as a store-and-forward protocol: a server can accept a message and store it for later processing, including local delivery or forwarding to another server. This design feature is terrifically useful because it allows mail to flow even if a server along the normal mail path is down. SMTP servers, by design, need to do Domain Name System (DNS) queries to find the host that handles mail traffic for a particular DNS domain. The responsible host for each domain must have a DNS mail exchanger (MX) record that points to the Internet Protocol (IP) address of the host. For example, the MX record for robichaux.net specifies that mail traffic for my domain should go to the machine named exchange.robichaux.net.

Here’s the neat feature: a single domain can have multiple MX records, each of which can have a different preference value. If your domain has more than one MX record listed, an SMTP server that’s trying to send mail to you is supposed to try the MX record with the lowest preference first. If that conversation fails, the sending server should then try the next-higher preference, and so on. When properly configured, each server identified by an MX record can store mail for later forwarding to the target server. Therefore, having multiple MX records means that mail sent to your domain will be accepted and stored somewhere for eventual delivery to your server.

To see this system in action, take a look at Figure 8-1, a skeleton diagram of the mail-handling system for my home lab. In this figure, the sender’s machine delivers its outbound message to an SMTP server. Figure 8-1 doesn’t show whether this delivery is done with Messaging Application Programming Interface (MAPI) or SMTP because we don’t care; the interesting part is what happens when the mail reaches that server. The sender’s server makes a DNS request for MX records for the destination domain and gets two of them: one for my server and one for the backup provider I use to catch mail when my server is unavailable. Because my server has a lower preference, the sending server tries my server first. If that delivery fails, the sending server tries again, this time with the backup provider. One of those two machines will eventually accept the mail, and it will be delivered to my mailbox server.

Figure 8-1: A simple routed SMTP environment.

What Relaying Is

Astute readers are now wondering what the previous section has to do with relaying. The answer is simple: the backup provider’s mail exchanger is relaying for my domain. It accepts mail from users in one DNS domain addressed to users in another, neither one of which it owns. The server stores that mail and forwards it to the destination system when it can. The recipients for whom mail is being relayed are known as nonlocal recipients. So the textbook definition is this: relaying is a process in which an SMTP server accepts mail addressed to nonlocal recipients and then attempts to deliver the mail to those recipients.

Why Relaying Is Necessary Sometimes

In practice, relaying comes in handy in several situations. We’ve already covered one: the use of backup SMTP servers for a particular domain. Most Internet service providers (ISPs), large and small, offer SMTP backup as a feature. To make the process work, mail must be accepted by the backup server even though the mail is in a different domain from the sender and the recipient. The solution is relaying.

A more common situation in which relaying is necessary is when clients using Post Office Protocol version 3 (POP3) or Internet Message Access Protocol version 4 (IMAP4) to pick up their mail use SMTP to send replies and new messages. Let’s say your Exchange server handles mail for the contoso.com DNS domain. One of your users, using IMAP4, might receive and reply to a message from a user with a return address in the fabrikam.com domain. That reply will be received by your Exchange server. If relaying is allowed, the message can be delivered to the server that handles mail for fabrikam.com. If relaying is turned off, your server will reject the message when the user attempts to send it—after all, the recipient is nonlocal.

A related situation is when you want to permanently accept mail for some other organization and relay it to that organization’s mail host. For example, if you were setting up Exchange for the National Football League, you might prefer to set up a single SMTP server to accept mail for each team’s domain names. Thus nfl.com would need to relay mail for saints.com, falcons.com, and so forth. This procedure is still relaying, but normally you’d accomplish it by setting up an SMTP connector, a topic discussed later in this chapter.

Yet another case when relaying can be useful is when you have applications, Web- based or otherwise, that generate SMTP mail for delivery to outside recipients. Such mail might require relaying.

How Relaying Can Get You in Trouble

A server that will relay mail from any sender to any destination domain, without authentication, is called an open relay. The problem with open relays is that spammers can easily find them. By scanning ranges of IP addresses for hosts that have port 25 open and then attempting to relay messages, spammers can quickly build lists of machines configured to relay first and ask questions later.

These lists, of course, are used to create spam and inject it into the Internet. By using open relays, spammers can get their messages delivered without having to pay anything themselves. But it’s not free! The relay owner gets stuck with the storage and bandwidth costs incurred by the spammer, including the cost of receiving, storing, and dealing with thousands of nondelivery reports (NDRs) and angry “stop spamming me” messages sent by irate recipients.

The following are some bad things that can happen as a result of your server being an open relay:

• Spammers can use your server to spam others. At best, if the spammer is “polite” and uses someone else’s return address, your server will merely be the target of abuse reports from furious recipients.

• If the spammer forges the mail headers so that the mail appears to originate from a mailbox in your domain, the spam will appear to have come from your server! That means you’ll be getting NDRs for undeliverable messages, along with complaints and threats.

• If any of the relay tracking systems on the Internet detects that your machine is an open relay, you might end up on a list of open relay servers. These blacklists are used by many e-mail admins - to make sure - their servers don’t accept spam. The problem is that some of the tracking services are astonishingly cavalier about managing their lists—so once you’re on one, it can be tough to get off. In the meantime, legitimate mail from your domain might be blocked by hosts that use the list or lists you accidentally ended up on.

Note

There are a thorny set of legal issues surrounding spam. In some jurisdictions, spamming is illegal, but the exact definition of and penalties for spamming vary widely.