Want to start a conversation with a stranger? Ask about the most outrageous spam message he or she has ever received. Because everyone who has an email account gets spam, this icebreaker is almost guaranteed to work—although the answer you get might embarrass one or both of you!

Many Exchange administrators use third-party mail filters, but Exchange Server 2003 has a surprisingly good set of built-in spam-reduction tools. In fact, Microsoft uses these tools as a first line of defense for its own systems, and Microsoft employees will generally tell you that they don't get much spam. Is your organization getting the most out of Exchange 2003's built-in tools? To answer that question, you need a thorough understanding of the tools, how they're applied, and your configuration options.

The Exchange Antispam Process
Exchange 2003 incorporates several types of antispam protection, including blocking mail from specific IP addresses or senders and filtering with the Microsoft Exchange Intelligent Message Filter (IMF). Exchange applies filtering techniques in a predictable-sequence. The process starts when a remote system opens an SMTP connection to the Exchange server. If the server is accepting connections, the following types of filtering take place:

1. Connection filtering—Exchange applies checks based on the sender's IP address and other data, such as whether the SMTP conversation has the correct syntax.
2. Sender and recipient filtering—Exchange checks for the sender's IP address on any blacklists and checks the sender and recipient addresses against its lists of permitted users and blocked users.
3. Content filtering—Exchange passes the message through the IMF (if it's enabled).

Exchange then submits the message to the mailbox store, where it may be acted upon by the store (according to options set in the IMF) or by the client-side Outlook junk mail filter.

Setting Up Filtering
You control which types of filtering are applied to your Exchange servers in two ways. First, you can use the Message Delivery node in Exchange System Manager (ESM) to specify filtering settings for the IMF, sender and recipient filtering, connection filtering, and Sender ID filtering. Each filtering type has its own tab in the Message Delivery Properties dialog box, as you can see in Figure 1.

Second, you can control which filtering mechanisms are applied to each SMTP virtual server in your organization. Open the SMTP virtual server properties and click the Advanced button on the General tab, then click Edit to display the Identification dialog box that Figure 2 shows. After you select the filtering types you want to apply, you must restart the SMTP virtual server for the options to take effect. The settings applied for each selected filter are drawn from the configuration data for each virtual server. Having independent filtering options for each virtual server gives you flexibility in how you filter inbound messages.

It's important to understand that although connection, sender, and recipient filtering happen at different times, they're all part of the SMTP conversation, so they're not really discrete operations.

Connection Filtering
Connection filtering is a catch-all term that includes several steps Exchange takes when accepting an SMTP connection. The connection begins when a remote server connects to the Exchange SMTP service. Exchange receives the sender's IP address and performs several checks.

• Exchange checks the sender's IP address against the lists of allowed and blocked IP addresses, which are stored in Active Directory (AD). The SMTP virtual server is smart enough to notice updates to the address lists without a service restart. If the IP address appears on the global accept list, the message is exempted from further checks. If the address is on the global deny list, the connection is immediately dropped. No nondelivery report (NDR) is generated, but the sending server receives a 5.7.0 Access Denied error message. Two sets of IP address lists are used for this step: The first set is the global accept and deny lists, defined on the Connection Filtering tab of the Message Delivery Properties dialog box, and the second set is the pair of accept and deny lists that are specific to the individual virtual server.
• If you've enabled reverse DNS lookups, Exchange uses the IP address to perform a reverse DNS check to verify that a DNS name is associated with the IP address. If no result is found, Exchange drops the connection.
• The Exchange server accepts the sender's HELO/EHLO message. If it's incorrectly formed, Exchange drops the connection.
• Exchange accepts the sender's MAIL FROM verb, which provides what's known as the envelope FROM (or P1) address. This address is who the sender claims to be, but Exchange makes no effort to verify it. However, Exchange does check the P1 address against the list of blocked senders. If the address is on the list, Exchange drops the connection with a 5.1.0 Sender Denied error message; otherwise, the Exchange server sends a 250 OK status message and the SMTP conversation continues.

If at any time during this process the Exchange filter mechanism sees SMTP verbs in the wrong sequence (e.g., DATA before MAIL FROM) or with obviously malformed arguments, Exchange drops the connection.

Sender and Recipient Filtering
At this stage, Exchange has accepted the P1 sender address and is ready to accept the list of message recipients. Before it does so, however, Exchange performs Realtime Blackhole List (RBL) checks. If you've configured Exchange with RBLs, Exchange checks the first RBL in the list by querying the RBL provider with the sender's IP address in reverse. For example, if the sender's IP address is a.b.c.d and the RBL provider is example.com, Exchange queries the RBL provider for d.c.b.a.example.com. If the RBL provider has a record for the sender's IP address, the provider returns a status code indicating which RBL contains the IP address; otherwise, it returns a Host Not Found error message.

Exchange queries each RBL on the list until it either finds a match or runs out of RBLs. When Exchange finds a match, the Exchange SMTP server returns a 5.7.0 error with an optional custom error message you can use to explain why the email message bounced. You can also define a list of recipients for whom RBL checks should not be performed (e.g., your postmaster or abuse mailboxes). Messages to those recipients are accepted, even if the sender's IP address is on an RBL, and are flagged to exempt them from further checks.

Next, Exchange accepts the RCPT TO verb, which specifies the message recipients. Like senders, recipients are checked against two lists: a list of blocked recipients (for whom all mail is refused) and a list of allowed recipients (for whom all mail is accepted). If the recipient doesn't appear on either list, what happens next depends on the Filter recipients who are not in the Directory setting on the Message Delivery Properties dialog box's Recipient Filtering tab that Figure 3 shows. When the check box is selected, Exchange compares the recipient alias against AD to ensure that the recipient is valid; messages to invalid recipients are returned with an NDR. When the recipient is valid or if the check box isn't selected, Exchange accepts the DATA verb, which contains the message contents.

The DATA conversation includes transmission of the message headers, which contain the sender's reply address (aka the P2 address). If this address appears on the sender filter list, Exchange drops the connection and deletes the message.

If the SMTP connection is still active and Sender ID checking is enabled, Exchange looks for a Sender Policy Framework (SPF) or Sender ID resource record on the DNS server. When a record for the purported sending domain is found, Exchange checks it against the sender's P1 address. If no record exists or if the record's information doesn't match the sender's P1 address, Exchange processes the message according to the setting selected on the Sender ID Filtering tab of the Message Delivery Properties dialog box, which Figure 4 shows. Because the Sender ID result factors into the IMF's decision about whether a message is legitimate, Microsoft recommends that you use the default of accepting messages even if they fail the Sender ID check. Few organizations have set up Sender ID records to date; as more organizations do, you'll want to consider enforcing Sender ID checks by deleting or rejecting messages from domains that don't have Sender ID records. (See Additional Resources for more information about Sender ID and IMF.)

Content Filtering
Content filtering is performed by the IMF. Unlike most third-party solutions, the IMF has few administrator-adjustable settings, depending instead on a corpus of filtering data that's produced by analyzing hundreds of thousands of messages sent to MSN Hotmail users. The IMF assigns messages two numerical scores: the spam confidence level (SCL) and the phishing confidence level (PCL). The higher the number, the more likely the message is illegitimate: An SCL of 9 means the IMF is sure the message is spam, whereas an SCL of 1 means the message is probably legitimate. An SCL of -1 means that the message was exempted from IMF scanning because it came from a trusted IP address or sender, was delivered over an authenticated connection, or came from another user in the same Exchange organization. The PCL is similar to the SCL, but it measures the likelihood that a message is phishing.

As Figure 5 shows, the IMF lets you control two threshold values: the gateway threshold, which controls the SCL at which messages are rejected; and the store threshold, which controls the SCL at which messages are accepted but routed to the user's Junk E-mail folder. (There are no corresponding settings for the PCL, unfortunately.) You can also tell Exchange what to do when a message exceeds the gateway threshold: Delete the message, reject it with an NDR, archive it for later inspection, or take no action. Microsoft recommends that you initially set gateway blocking to No Action, then let the filter run for a few days and use the IMF's performance counters to help you decide where to set the gateway SCL.

You can make a couple other adjustments to the IMF, although they're not exposed in the UI. For example, you can define a custom word list as an XML file (stored in MSExchange.UceContentFilter.xml in the \exchsrvr\bin\MSCFV2 directory) and adjust the SCL up or down for messages that contain the specified words. This is a useful function, provided you're careful about which words you include. You can also use the CustomRejectResponse registry key to force the IMF to return a custom SMTP response for messages that are rejected (e.g., 550 5.7.0 Die, spammers, die!). There's really nothing else to adjust or set. This simplicity is an advantage for many sites, though some administrators want more granular control over which messages are accepted and rejected.

The Future Looks Good
Exchange Server 2007 adds several new features. The basic IMF engine is largely the same, but it runs as part of the Content Filtering agent, a component that runs on the Hub Transport or Edge Transport server role to protect your network by filtering messages at the perimeter.

Exchange 2007 also introduces Automatic Updates to the IMF's filter corpus; a UI for setting the IMF's custom words list; and a flexible engine for defining rules to block, quarantine, forward, or drop messages according to criteria such as subject, attachment size or type, sender, and recipient. The Edge Transport server role can collect safe and blocked sender lists from individual Outlook mailboxes and aggregate them for perimeter filtering, and there are a host of other minor tweaks.

However, these improvements don't change the fact that Exchange already has a robust set of antispam tools that are included at no extra cost. If you're not using them, give them a try to see how well they meet your needs. You might find that the cost of maintaining message hygiene drops significantly without decreasing the degree of protection you get.