Spam is arguably the single biggest external problem that email administrators face today. Estimates of the total volume of spam vary; many businesses report that as much as 75 to 90 percent of incoming SMTP connections are spam attempts. Spam is no longer merely a nuisance; it represents a significant waste of bandwidth, disk space, CPU utilization, and time. Furthermore, spam poses a serious threat by providing an entry point for viruses, Trojan horses, worms, and social-engineering attempts.

No matter what size Microsoft Exchange Server organization you manage, you already have access to powerful server-side tools to fight spam and protect users. Exchange Server 2003 and Exchange 2000 Server both come with built-in tools; other tools are available for download from Microsoft. (You'll get the most benefit by using Exchange 2003, so that's the version I'll cover, but many of these techniques will also work with Exchange 2000.) Although Microsoft Outlook Web Access (OWA) and Outlook provide client-side spam-fighting technologies, this solution sticks with server-based technologies that deal with the SMTP transport.

Because no one technique or tool will remove all spam, you need to concentrate on an essential principle: Use as few resources as you can to remove the maximum amount of spam as close to the edge of the network as possible, while minimizing the loss of legitimate messages. Your goal shouldn't be 100-percent elimination of spam, but you can reduce incoming spam to an acceptable level by following a strategy of defense-in-depth and blocking spam from the network edge in. Many of Exchange's built-in features are useful only when used at the organization's edge. Whichever features you use, you will find them to be most effective when used in multiple stages to provide a layered defense. The earliest stages, which are relatively inexpensive in terms of resource use, block the most spam; the later stages are more computationally expensive but need to be run on only a fraction of messages.

There are three main stages of server-side spam blocking: connection filtering, header filtering, and body filtering. We'll take each stage in turn.

Stage 1: Connection Filtering
Your first line of defense is to refuse incoming connections from known spam sources. Many spam attacks can be stopped in their tracks by rejecting connection attempts. The sending system (which might be nothing more than a computer infected by a worm or Trojan horse) generates each message and submission attempt on the fly and doesn't bother to queue rejections. Other messages are relayed through legitimate but insecure systems; some messages are even forged to look like non-delivery reports (NDRs) that originate from users. Refusing to let such systems connect can reduce the load on your message-hygiene solutions.

Conversely, you don't want to waste resources checking for spam from sources that you trust. You already know that you want to accept messages from your business partners and other well-known senders. Even if those sources' outbound message hygiene isn't as conscientious as yours, the amount of actual spam that comes from them is likely to be relatively small. By accepting these connections, you bypass unnecessary layers of filtering and let the most-relevant tools process messages more quickly. The catch is that this type of filtering can be performed only by the first network SMTP server to accept the connection. You can use Exchange in this edge role as long as you properly secure it by using appropriate firewalls and server-hardening techniques.

Accept and Deny lists. When using Exchange connection filtering, you can define one Accept or Deny list per SMTP virtual server. Although you must separately configure each virtual server, each per-server list can specify multiple connections by IP address, subnet, or domain name. To configure the connection filter for an SMTP virtual server:

1. Open the Exchange System Manager console, then open the virtual server's Properties dialog box.
2. Go to the Access tab and click Connection. Click Only the list below to define machines that the filter will let connect to the virtual server, or click All except the list below to define machines from which the filter will reject connections.
3. Enter a new entry. You can provide a single IP address (e.g., 192.168.5.15), an IP subnet and netmask (e.g., 192.168.5 and 255.255.255.0), or a domain name (e.g., 3sharp.com) to define each entry in the chosen list.

The simplest connection filter is the global Accept and Deny functionality available in Exchange 2003. These lists provide a quick way to set a universal filter throughout your organization, according to the IP address of an incoming connection. You can have both a global Accept and Deny list defined simultaneously. To define a global Accept or Deny list:

1. In Exchange System Manager, expand Global Settings and open the Message Delivery item's Properties dialog box.
2. On the Connection Filtering tab, choose either Accept or Deny. The current entries on the chosen list will be displayed.
3. Add an entry to the list by selecting the appropriate option: a single IP address or an IP subnet and netmask, then enter the appropriate information. Repeat this step as often as necessary until you have all the desired entries on the list. If you need to have both an Accept and Deny list, follow these steps again and create the second list.

Once you have configured a connection filter, you must enable it on one or more virtual servers.

1. In the Exchange System Manager console, navigate to the SMTP virtual server you want to enable connection filtering on and right-click it to open the Properties dialog box.
2. Go to the General tab and click Advanced. Select the IP address of the virtual server to which you want to apply the filter and click Edit.
3. On the Identification dialog box, which Figure 1 shows, select the Apply Connection Filter check box.

If you want to maintain the virtual server and global Accept and Deny lists through a command line or script, you can download the Microsoft Exchange Server SMTP Inter-net Protocol Restriction and Accept/Deny List Configuration tool (http://tinyurl.com/ apxu6).

Reverse DNS lookups. Another type of connection filtering is reverse DNS lookup, which compares the IP address of an incoming connection with the host and domain name that the sending client claims during the SMTP transaction. If these don't match, Exchange adds the string unverified to the message's Received header. If the reverse DNS lookup fails, Exchange adds the string RDNS failed to the message's Received header, as Figure 2 shows. Not all legitimate senders properly set reverse DNS, so be cautious when using this feature to classify messages as spam. Also be aware that enabling reverse DNS lookup can have a negative impact on performance because it performs additional DNS lookups for each connection. To enable reverse DNS lookup:

1. In Exchange System Manager, open the SMTP virtual server's Properties dialog box.
2. Go to the Delivery tab and click Advanced.
3. In the Advanced Delivery dialog box, select the Perform reverse DNS lookup on incoming messages check box.

Real-Time Block Lists. You can use Exchange 2003's DNS-based Real-Time Block Lists (RBLs—sometimes referred to as Real-Time Blackhole Lists or Real-Time Blacklists) to define one or more dynamic lists through special DNS zones. You can use existing RBL services or create your own. Exchange checks every incoming connection against all defined RBL entries. Again, be aware that using this option with many lists can create a significant amount of DNS overhead. You'll also need list-specific query domain and result codes to add a new list. To enable the use of RBLs:

1. In Exchange System Manager, expand Global Settings and open the Message Delivery item's Properties dialog box.
2. On the Connection Filtering tab, click Add. Enter a display name, query domain (DNS suffix), and optional custom error message.
3. Click Return Status Code and configure the specific return codes you want to filter. Click Match Filter Rule to Any Return Code to block all RBL matches. Click OK.
4. To use multiple lists, arrange them in order of priority.
5. To exclude certain email addresses from RBL filtering, click Exception and enter the addresses in the list.
6. To exclude certain IP addresses or subnets from RBL filtering, add them to the Global Allow list.

You can choose from hundreds of RBLs, each of which has its own listing criteria and intended audience. Some RBLs list static network data; most are dynamic but vary in how often they update data. The news .admin.net-abuse.blocklisting Usenet news-group provides a moderated discussion forum for all RBL-related issues, and you can find a good RBL list at Email-policy.com (http://www.email-policy.com/spam-blacklists.htm).

On the edge. Connection filters work solely with the IP address or domain of the sending machine. As a result, these filters can be successfully deployed only on servers at the edge of your organization. If you have a separate inbound SMTP relay (such as a third-party antispam or antivirus solution) between your Exchange organization and the Internet, you won't be able to use Exchange's connection-filtering features directly. Look for equivalent functionality in your inbound relay server. Although using a non-Exchange solution in the edge role is common practice, many companies are finding that the combination of Exchange 2003 and Microsoft Internet Security and Acceleration (ISA) Server 2004 provides a secure, scalable edge solution. The details of Exchange edge-server hardening are outside the scope of this article, but Microsoft provides a wealth of guidance, including the Exchange Server 2003 Security Hardening Guide (http://tinyurl.com/25hlf) and the Security Operations Guide for Exchange 2000 Server (http://tinyurl.com/blvdb).

Stage 2: Header Filtering
The second layer of defense—header filter-in—looks at message properties. Because of the way SMTP works, the sender has already transmitted the message and consumed bandwidth before header filters can examine it. You want to use filters that operate before Exchange signals final acceptance of the message; if the message is bogus, you don't want to accept it only to have it waste your queue space with an NDR (or worse, generate an NDR to an innocent person whose email address was forged). You can filter by sender or by recipient. As with connection filters, you must enable the processing of sender and recipient filters on each virtual server.

Depending on your configuration, you might be able to reduce spam by placing your local domain addresses in a sender filter, which you define globally within the organization. To define a sender filter:

1. In Exchange System Manager, expand Global Settings and open the Message Delivery item's Properties.
2. On the Sender Filtering tab (or the Filtering tab, in Exchange 2000), click Add and enter the address you want to filter. This address can be specific (e.g., deving@ 3sharp.com); a display name, in quotation marks (e.g., "Devin L. Ganger"); or a group of addresses, designated with the asterisk wild-card (e.g., *@3sharp.com, *@.3sharp.com).
3. To reject messages that list no sender, select the Filter messages with blank sender check box. This option looks at the message header, not the SMTP envelope.
4. You can tell Exchange to drop connections from a sender address that you've put on the sender list. This action won't generate an NDR. (If you don't specify this option, Exchange will accept the message but will generate an NDR instead of delivering the message.) Be careful with this option, which can cause a temporary mail blockage on remote mail systems. SMTP systems are designed to attempt delivery until a message is accepted, rejected, or reaches the configured timeout period.

Exchange 2003 adds the ability to configure recipient filters, which are much like sender filters but are configured on the Message Delivery object's Recipient Filtering tab. You can also use the settings on this tab to configure Exchange to refuse messages for invalid recipients. Whether doing so is a good idea is hotly debated: Some people think it leads to directory-harvesting attacks. However, I advise using the feature because it decreases the load on your systems and on the systems of forgery victims. A sufficiently motivated spammer can (and will) harvest addresses simply by using a valid return address and NDRs.

By default, neither Exchange 2003 nor Exchange 2000 permit open relays for anonymous clients. However, if you authenticate to the SMTP server, you can submit messages for any recipient and Exchange will relay those messages. Combine this fact with the lack of out-of-the-box auditing of SMTP authentication attempts and you get an attack that looks for accounts that have weak passwords. Attackers can use such accounts to turn a victimized Exchange server into an open relay. Unless you need SMTP authentication for external users, you should disable authenticated relay:

1. In Exchange System Manager, open the SMTP virtual server's Properties.
2. Click Relay on the Access tab. Clear the Allow all computers which successfully authenticate to relay, regardless of the list above check box.

Stage 3: Body Filtering
The final stage of defense looks at the entire message, using a combination of properties to determine whether the message is spam. To get this functionality for free, install the Microsoft Exchange Intelligent Message Filter (IMF) for Exchange 2003. IMF version 2 is included in Exchange 2003 Service Pack 2 (SP2). If you're using Exchange 2003 SP1 or release to manufacturing (RTM), you can download IMF version 1 at http://tinyurl.com/aetsm. This free server-side filter integrates with the existing Spam Confidence Level (SCL) framework within Exchange 2003 and Outlook 2003. If you're upgrading to Exchange 2003 SP2 and already have IMF version 1 installed, you need to uninstall IMF first. After you install SP2 on the server, you'll need to manually enable IMF version 2 by following the same steps you used to enable connection filtering.

The IMF looks at each message and uses multiple indicators and factors to determine the percentage of certainty that the message is spam. This percentage is in turn translated into an SCL, which is a number from 1 to 9 that represents the probability that the message is spam. The IMF stores the SCL in the message's MAPI properties. You can configure the Exchange Information Store to block messages that have a specified SCL or higher, and clients that are aware of the property (as of this writing, Outlook 2003 and any clients that use OWA 2003) can take further action, such as moving the message to the Junk E-mail Folder. The IMF filters only messages that come in through SMTP, which is Exchange's default transport. IMF version 2 also gives you the ability to integrate Sender ID checks, as well as a modifiable, weighted word list so you can customize IMF screening (something you can't do with IMF version 1).

Freedom Fighters
I've given you a whirlwind tour of some of the built-in or free Exchange server-side options that you can use to fight spam. (I've also given you some good reasons to begin deploying Exchange 2003, if you haven't already done so.) Many live Exchange deployments are using these techniques right now to successfully manage spam. You can, too.