Coping with Unsolicited Email

The proliferation of unsolicited commercial email (UCE, aka spam or junk mail) has changed the way companies operate in the Internet email world. Although some ISPs have prohibited UCE on their servers, unscrupulous mailers get around the prohibition by using other organizations' mail servers to relay their mail. As a result, companies have tightened their server security to the extent that some innocent mail servers can't communicate with the security-conscious servers. However, the fact remains that companies want to block the flood of unwanted mail. Let's look at how you can ensure that outsiders don't mistake your Exchange installation for a UCE mailer and how you can configure Exchange to follow current Internet standards for preventing UCE.

Understanding Lockdown Measures
In this article, I use the Sendmail program as a reference because it's the most widely implemented mail program on the Internet and the most widely encountered SMTP software your Exchange server talks to. Developed in the UNIX environment, Sendmail is the original mail relay program; it lets you route messages between different mail systems. You can find the latest version of the program at the Sendmail Consortium's Web site (http://www.sendmail.org). Sendmail Inc.'s Web site (http://sendmail.com) offers a commercial port to Windows NT. The current version, Sendmail 8.9.3, implements much better UCE control measures than version 8.8 did.

You can use two primary methods to close the holes that UCE mailers use. First, you can disable promiscuous relaying (i.e., relaying mail for any remote SMTP server). The default in Sendmail 8.9.0 and later versions is not to relay mail.

Second, you can limit your exposure to UCE by performing DNS reverse lookups on the IP addresses of all connecting mail servers to determine their host names. This measure is effective because the Internet Engineering Task Force's (IETF's) Request for Comments (RFC) 1123 requires that all Internet mail servers have a corresponding Reverse Lookup, or PTR (short for pointer), record in the Internet DNS. This record lets you enter an IP address and discover the host name and domain name associated with it. Many UCE mailers use incorrectly configured or unofficial mail servers that don't conform to this standard, so if a reverse lookup fails, you can reject mail from that server. Although some mail server installations have only recently begun using reverse lookups as a basis for denying connections, most Internet mail servers use this capability to capture the host name in the Received lines of the message headers for manual message tracking.

Configuring Reverse Lookups
Disabling promiscuous relaying and implementing reverse lookups have helped reduce UCE, but a nasty side effect is that well-intentioned SMTP servers can't send mail to newer servers because the SMTP servers don't have a Reverse Lookup record in the Internet DNS. This problem occurs most frequently in Exchange Server installations, where many administrators don't come from a UNIX background and aren't familiar with the current Sendmail and Internet RFC SMTP conventions. These mail servers increasingly have trouble communicating with security-enabled domains, and current administrators are paying the price for the faulty configuration.

Problems with sending mail to remote servers display two symptoms. The first symptom appears in the Internet Mail Service (IMS) queue. From the Internet Mail Service object in the Microsoft Exchange Administrator program, go to the Queues tab. Look at the details of any messages queued for delivery retries. You might have a problem if you see the following types of error messages:

418 unresolvable host name XXX, check your setup.
451 unresolvable relay host name XXX, check your setup.

These error types, which the remote mail server sends, signal that reverse lookups on your server's IP address failed. The error codes and text can vary, depending on the remote SMTP software, so look for the words unresolvable or must resolve in the error message text. These 400-series SMTP error codes reflect a transient failure, which means that your mail server will continue to attempt delivery of these messages until they time out and the server returns them to the sender, usually 48 hours later.

The second symptom is when end users report difficulty in sending messages to certain—but not most—domains. Check the users' nondelivery reports (NDRs) for the 400-series errors. In one situation I encountered recently, only some mail sent to a certain large ISP's domain was failing, but most mail was going through. This behavior occurred because this ISP had more than 50 mail servers for its domain, but the company had upgraded only a few servers to the latest anti-UCE version of Sendmail. Because DNS rotates multiple host records on successive lookups as a simple form of load-balancing—a technique known as round-robin addressing—sometimes the chosen server accepted the mail, and sometimes it didn't. I expect that over time the ISP will upgrade more of the servers, and the delivery problem will get worse.

If you experience either symptom, you can easily verify whether you have reverse lookups enabled for your mail server. From the command prompt of a computer connected to the Internet, issue a Ping command with the -a option to the Internet IP address of your mail server. This option performs a reverse lookup on your mail server's IP address before sending the ping queries. If the header line includes the Fully Qualified Domain Name (FQDN) of your mail server, you have a valid PTR record for your mail server.

For example, if you run

C:>ping -a 10.1.1.1

and the ping doesn't return a host name, your server doesn't have a PTR record. In this case, contact your ISP about setting up a reverse DNS zone for the network your server is on and inserting a PTR record for it. If you manage your own Internet address block and DNS servers, you need to set up a reverse zone for your network. For example, if your Internet address block is the class C network 204.44.36.0, create the reverse lookup domain 36.44.204.in-addr.arpa on your DNS server. This entry is the network portion of your address block in reverse, with the global in-addr.arpa domain appended. Then, enter a PTR record into this domain; the record contains your mail server's IP address and FQDN.

You also need to inform the Internet of your reverse lookup name servers by contacting your organization for IP address block allocation. The three addressing organizations are American Registry for Internet Numbers (ARIN—http://www.arin.net) for North and South America, Réseaux IP Européens (RIPE—http://www.ripe.net) for Europe, and Asia Pacific Network Information Center (APNIC—http://www.apnic.net) for Asia and Pacific countries.

To determine the owner of the network your server is on, check your regional organization's Whois database. If you reside in North America, for example, connect to http://whois.arin.net/whois/arinwhois.html, enter your mail server's IP address, and click Submit. The response is the organization responsible for that address block, the local contact, and the block's reverse lookup name servers.

Locking Down Exchange
After you've configured your Exchange installation so that recipients won't mistake you for a UCE mailer, you can configure Exchange to follow the security standards for inbound mail that the Sendmail world uses. First, tell Exchange not to relay all incoming mail indiscriminately. To disable this behavior, go to the Routing tab of the Internet Mail Service object, and select Do not reroute incoming SMTP mail, as Screen 1 shows. Be careful, however, because if you currently support POP3 or IMAP4 clients on your Exchange server, disabling routing prevents those clients from sending external mail. This behavior occurs because POP and IMAP clients use SMTP to transfer external mail to the Exchange server; because this mail is by nature nonlocal, Exchange must relay the message to deliver it.

To retain the ability to route mail but also limit the hosts that can relay messages, leave routing enabled and configure routing restrictions. Click Routing Restrictions on the IMS Routing tab. Exchange Server 5.5 Service Pack 1 (SP1) introduced this GUI feature; previously, you needed to use Registry entries to perform this task. In the Routing Restrictions window you see in Screen 2, you can tell Exchange to route mail only if the connecting server meets any of these conditions:

Condition 1. The sender authenticates to this server successfully. Exchange relays messages only for connecting servers that provide the proper credentials through the Enhanced SMTP standard Auth command or through NT LAN Manager (NTLM) credentials.

Condition 2. The sender's IP address appears on a list. You specify the individual IP or network address of servers that can relay mail. Exchange implements this option as an IP Address/Mask pair; therefore, to allow a host with an address of 10.1.1.20 to relay mail, you enter 10.1.1.20 / 255.255.255.255, as you see in Screen 2. Theoretically, you can specify a range of servers by entering, for example, 192.168.0.0 / 255.255.0.0. However, this system didn't work when I tried it, so I had to enter the server IP addresses individually, each with a 255.255.255.255 mask. Therefore, be sure to test thoroughly if you enter a range of servers.

Condition 3. The sender connects to an internal network adapter's IP address. You specify an internal network adapter IP address that allows mail relaying. However, this option assumes that you have a multihomed Exchange server with internal and external network cards.

Condition 4. The sender's IP address isn't on a list of prohibited hosts and clients. You specify IP addresses or ranges that can never use the Exchange server for relaying mail. You can use this option in combination with option 2 to give fine-grained control over which addresses can relay messages, without manually entering many individual addresses. For more information about entering these addresses, see the Microsoft article "XFOR: Preventing the IMS from Relaying UCE Messages" (http://support.microsoft.com/ support/kb/articles/q193/9/22.asp).

If a host that doesn't meet one of the four conditions tries to relay mail, it receives the 550 Relaying is prohibited SMTP error message. You can test your mail server for anonymous relaying by performing these steps:

For example, from the command prompt, type

C:>telnet mail.example.com 25

In the Telnet window, go to Terminal, Preferences and select the Local Echo check box to see what you're entering. Now, enter the following commands in response to the noted system messages, substituting your domain name for :

220 mail.example.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2448.0) ready

helo 

250 OK

mail from:

250 OK-mail from

rcpt to:

550 Relaying is prohibited

quit

If you receive a 250 Recipient OK message instead of the 550 error message, the server has enabled anonymous relaying. Try to disable routing or limit relaying by using the Routing Restrictions tab, and see whether you get a different result. Be sure to restart the IMS after you make any changes. If you receive the 550 error, you know that UCE mailers can't use your server as an unauthorized relay. Because UCE mailers receive a 500-series fatal error, the UCE mail server doesn't attempt any retransmissions and returns the offending message to the sender immediately.

If you want to use Exchange as a pure SMTP relay host between your internal Exchange organization and the Internet, you must enable routing. However, then you need to prevent UCE mailers from using your server to relay by using a new feature in SP2. First, set up the routing restrictions to let only your internal Exchange servers relay mail. On the Routing tab, click Add to enter a routing table entry for your internal domain name (i.e., example.com), and select the new option Override relay restrictions. Always "relay," which Screen 3 shows. This neat new feature lets all inbound mail to your domain relay properly but lets only the specified internal servers relay outbound mail.

As I described previously, Sendmail verifies server authenticity by performing a reverse DNS lookup on the IP address of the connecting host. Exchange Server also performs this check to populate the Received line of the message header, but it won't drop an incoming connection if the reverse lookup fails. I hope Microsoft recognizes the need for this capability in future Exchange releases.

Blocking UCE
Exchange offers several methods to block UCE mail. The Accept Connections option on the Internet Mail Service Connections tab, which Screen 4 shows, lets you specify that certain hosts use authentication, encryption, or both when connecting to your server. Because authentication and encryption aren't yet widely used on the Internet for SMTP for general mail transfer, I won't describe this feature in detail. These procedures are most applicable in situations in which an organization's servers need to communicate privately via a public network such as the Internet.

The Message Filtering option in Accept Connections on the IMS Connections tab can help prevent UCE mail if you know where the mail originates. Exchange Server 5.5 SP1 introduced a GUI for this feature, which you see in Screen 5. Message Filtering lets you create a list of senders or domains from which you want to stop inbound mail. The server accepts mail from entries in the list and then either deletes the mail immediately or moves it to a turf directory for inspection later. The server doesn't return NDRs to the sender in this case.

I recommend that you use Message Filtering only when you know that the sender is an offensive UCE mailer. Message Filtering sends mail into a black hole: Exchange neither delivers it nor returns a delivery status report to the sender. This procedure goes against the Internet's fundamental mail philosophy of guaranteeing message delivery. This practice also can clog Help desks with calls from employees who have subscribed to a filtered mailing list but don't receive the messages. I recommend that companies that want to restrict mail inform employees of their policy.

If you use Message Filtering, you must manually create the turfdir directory in the root of your system drive to hold these messages; Exchange doesn't create it for you. You can modify the location of the directory by changing the value of the HKEY_LOCAL_MACHINE/SYSTEM/ CurrentControlSet/ Services/ MSExchangeIMC/Parameters/TurfDir Registry key to the path you want. As always, back up the Registry before you edit it and make changes with care.

To extend Exchange Server's built-in blocking features, you can use third-party and shareware products to reduce the amount of UCE. The solutions range from desktop and server-based solutions to completely outsourced UCE filtering services. The sidebar "Third-Party UCE Countermeasures," page 2, describes a few server-based products.

Screen Your Mail
To counter the proliferation of UCE, companies are increasingly cracking down on UCE mailers by securing their domains. If you follow the recommendations I've discussed, you can not only inhibit UCE mailers from trying to deliver inbound messages to your domain but also minimize the problems that your users might experience with sending mail to other security-enabled domains. The sidebar "For More Information" lists some resources to help you implement my suggestions.