Fight Spam for Free

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).