Fight Spam for Free

Spam is arguably the single biggest external problem that email administratorsface today. Estimates of the total volume of spam vary; many businesses reportthat 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 threatby providing an entry point for viruses, Trojan horses, worms, and social-engineeringattempts.

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

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 spamsources. Many spam attacks can be stopped in their tracks by rejecting connectionattempts. The sending system (which might be nothing more than a computer infectedby a worm or Trojan horse) generates each message and submission attempt onthe fly and doesn't bother to queue rejections. Other messages are relayed throughlegitimate but insecure systems; some messages are even forged to look likenon-delivery reports (NDRs) that originate from users. Refusing to let suchsystems 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:

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:

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

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

Reverse DNS lookups. Another type of connection filtering isreverse DNS lookup, which compares the IP address of an incoming connectionwith the host and domain name that the sending client claims during the SMTPtransaction. If these don't match, Exchange adds the string unverified tothe message's Received header. If the reverse DNS lookup fails, Exchange addsthe string RDNS failed to the message's Received header, as Figure2 shows. Not all legitimate senders properly set reverse DNS, so be cautiouswhen using this feature to classify messages as spam. Also be aware that enablingreverse DNS lookup can have a negative impact on performance because it performsadditional DNS lookups for each connection. To enable reverse DNS lookup:

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:

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 addressor domain of the sending machine. As a result, these filters can be successfullydeployed only on servers at the edge of your organization. If you have a separateinbound SMTP relay (such as a third-party antispam or antivirus solution) betweenyour Exchange organization and the Internet, you won't be able to use Exchange'sconnection-filtering features directly. Look for equivalent functionality inyour inbound relay server. Although using a non-Exchange solution in the edgerole is common practice, many companies are finding that the combination ofExchange 2003 and Microsoft Internet Security and Acceleration (ISA) Server2004 provides a secure, scalable edge solution. The details of Exchange edge-serverhardening are outside the scope of this article, but Microsoft provides a wealthof guidance, including the Exchange Server 2003 Security Hardening Guide(http://tinyurl.com/25hlf) and the Security Operations Guide for Exchange2000 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 messageand consumed bandwidth before header filters can examine it. You want to usefilters 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 yourqueue space with an NDR (or worse, generate an NDR to an innocent person whoseemail address was forged). You can filter by sender or by recipient. As withconnection filters, you must enable the processing of sender and recipient filterson 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:

Exchange 2003 adds the ability to configure recipient filters, which are muchlike sender filters but are configured on the Message Delivery object's RecipientFiltering tab. You can also use the settings on this tab to configure Exchangeto refuse messages for invalid recipients. Whether doing so is a good idea ishotly debated: Some people think it leads to directory-harvesting attacks. However,I advise using the feature because it decreases the load on your systems andon the systems of forgery victims. A sufficiently motivated spammer can (andwill) 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:

Stage 3: Body Filtering

The final stage of defense looks at the entire message, using a combinationof properties to determine whether the message is spam. To get this functionalityfor free, install the Microsoft Exchange Intelligent Message Filter (IMF) forExchange 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 candownload IMF version 1 at http://tinyurl.com/aetsm. This free server-side filterintegrates with the existing Spam Confidence Level (SCL) framework within Exchange2003 and Outlook 2003. If you're upgrading to Exchange 2003 SP2 and alreadyhave IMF version 1 installed, you need to uninstall IMF first. After you installSP2 on the server, you'll need to manually enable IMF version 2 by followingthe same steps you used to enable connection filtering.

The IMF looks at each message and uses multiple indicators and factors to determinethe percentage of certainty that the message is spam. This percentage is inturn translated into an SCL, which is a number from 1 to 9 that represents theprobability that the message is spam. The IMF stores the SCL in the message'sMAPI properties. You can configure the Exchange Information Store to block messagesthat 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 takefurther action, such as moving the message to the Junk E-mail Folder. The IMFfilters only messages that come in through SMTP, which is Exchange's defaulttransport. 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-sideoptions that you can use to fight spam. (I've also given you some good reasonsto begin deploying Exchange 2003, if you haven't already done so.) Many liveExchange deployments are using these techniques right now to successfully managespam. You can, too.