Anti-Spam Enhancements in Exchange Server 2003 Service Pack 2


Topic Last Modified: 2006-04-05

In the business world, a reliable, effective, and robust e-mail system is one of the keys to success. Keeping your e-mail system healthy and efficient is essential to business health, but in recent years, as the volume of unsolicited commercial e-mail (UCE), or spam, has exploded, this task has become increasingly difficult for IT professionals.

The Coordinated Spam Reduction Initiative, announced by Microsoft® in 2004, clearly outlines a roadmap and technology infrastructure to help reduce the volume of spam.

We should differentiate between alleviating the spam problem and completely eliminating it. Eliminating spam completely will take a long time. In the meantime, we must be ready for an extended coexistence of spam and legitimate mail, and work to reduce spam and its impact.

In this article, I describe the message hygiene and anti-spam enhancements provided in Microsoft Exchange Server 2003 Service Pack 2 (SP2). In this article, the term message hygiene refers collectively to the Exchange Server 2003 SP2 features deployed throughout the messaging environment to help combat spam.

Exchange Server 2003 SP2 represents an important step toward alleviating the spam epidemic. Let’s look at what it provides.

Sender ID   Exchange Server 2003 SP2 delivers the long-awaited Sender ID filtering technology, which primarily targets forgery of e-mail addresses. The elimination of spoofed mail will immediately cause a significant reduction of mail traffic into the Exchange organization. Preliminary data from the internal IT department at Microsoft shows that enabling the Sender ID filter allowed Microsoft to achieve an approximately 10 percent net increase in spam capture before mail is transmitted to Exchange Intelligent Message Filter for additional anti-spam processing. Stopping spoofed mail at the gateway is important because the reduction of mail traffic into the Exchange organization reduces bandwidth consumption and eliminates the overhead of processing these messages in the internal mail infrastructure.

Intelligent Message Filter   A second important addition to the existing Exchange Server 2003 anti-spam features is the inclusion of Microsoft SmartScreen™ technology in the form of Intelligent Message Filter. Previously, Intelligent Message Filter was available as an add-in tool only. Now Intelligent Message Filter is an important part of Exchange Server 2003. Intelligent Message Filter contains updated spam characteristics that improve its ability to block spam. And on top of that, Intelligent Message Filter provides anti-phishing protection.

Connection Filtering Behind the Perimeter   Connection filtering was introduced in Exchange Server 2003, but it worked from the network perimeter only. Because most servers running Exchange Server 2003 are positioned behind the network perimeter, the Connection filtering functionality was not possible. Exchange Server 2003 SP2 changes all this by enabling deployment of connection filtering not only at the network perimeter, but behind it too. Now you can take full advantage of message hygiene and anti-spam enhancements, regardless of where your Exchange server is deployed.

Before you enable Sender ID on a server running Exchange Server 2003 SP2, make sure to apply the Microsoft Windows Server™ 2003 hotfix that is documented in Microsoft Knowledge Base article 905214, “Windows Server 2003 or Windows 2000 Server may stop responding when you enable the “Sender ID Filtering” setting on an SMTP virtual server in Exchange Server 2003 SP2."

If you are running Microsoft Windows® 2000 Server, contact Microsoft Product Support Services (PSS) for support assistance. Windows 2000 Server is in extended support mode only.

Sender ID focuses on one of the most common and deceitful practices used by spammers: domain spoofing. The term domain spoofing refers to the use of someone else's domain name when sending a message. Domain spoofing is part of the larger problem of spoofing, which is the practice of forging a sender's address on e-mail messages. Domain spoofing can also be used by malicious individuals in phishing scams, which try to lure consumers into disclosing sensitive personal information by pretending the e-mail is from a trusted source, such as a consumer's bank. Disclosure of such information could lead to identity theft and other online consumer fraud.

Sender ID is an e-mail authentication protocol that verifies the origin of the e-mail and prevents forged mail from entering an Exchange organization. In essence, Sender ID asks a question: “Has this e-mail message been spoofed?” If the answer is “Yes, it has been spoofed,” the Sender ID filter rejects or deletes the message immediately. If the answer is “No, we can confirm the sender’s authenticity,” the message is assigned a Sender ID status and transmitted to Intelligent Message Filter, if Intelligent Message Filter is enabled on the server, for additional anti-spam processing.

So how does Sender ID work? Sender ID functionality relies, in part, on an algorithm that is implemented in the Sender ID filter detects the purported responsible address (PRA). PRA is the e-mail address of the entity that is most recently responsible for injecting a message into the e-mail system. The Sender ID filter determines the actual e-mail domain by locating the first definition of the following RFC2822 message headers in this order:

  1. Resent-Sender

  2. Resent-From

  3. Sender

  4. From

If none of these headers is found, the Sender ID filter uses the STMP RFC 2821 MAIL FROM value.

Figure 1   How Sender ID Works


Here are the steps in the Sender ID verification process in Figure 1:

  1. A sender sends an e-mail message to the receiver.

  2. The receiver’s inbound mail server receives the e-mail message and extracts the PRA.

  3. The inbound mail server checks which domain claims to have sent the message, and examines the domain name system (DNS) for the sender policy framework (SPF) record of that domain. These SPF records identify authorized outgoing e-mail servers. The inbound server determines whether the sending e-mail server's IP address matches any of the IP addresses that are published in the SPF record. For more information about what an SPF record contains and how to create an SPF record, see Sender ID.

  4. If the IP addresses match, the e-mail message is authenticated and delivered to the receiver. If the IP addresses do not match, the e-mail message fails authentication and is not delivered.

Based on the evaluation of the Sender ID record, every message is stamped with a Sender ID status. Intelligent Message Filter considers this status for the final assignment of an SCL rating, if Intelligent Message Filter is enabled on the server and the status is also available as an output from the Sender ID filter.

The Sender ID status reflects the results of the Sender ID filtering process. The Sender ID status can be one of the following:

  • Pass   The IP address for the PRA is in the permitted set in DNS.

  • Neutral   Published Sender ID data is explicitly inconclusive.

  • Softfail   This value indicates a weaker type of failure. The IP address may not be in the permitted set in DNS.

  • Fail   The IP Address is in the not permitted set in DNS.

  • None   No published data is available.

  • TempError   There is a transient error, such as an unavailable DNS server.

  • PermError   There is an unrecoverable error, such as an error in the record format.

Sometimes, for example, when there is a misconfiguation of the operating environment, the “FROM” IP address may be missing on an inbound message. Therefore, Sender ID status cannot be set. In this case, message processing continues without assigning a Sender ID status to the e-mail message.

A new performance object has been added to the System Monitor: MSExchange Sender ID with counters that correspond to the Sender ID statuses described earlier. The following counters are available for the Sender ID filter:

  • Total DNS Queries

  • Total Messages Missing Originating IP

  • Total Messages Validated by Sender ID

  • Total Messages Validated with a Fail – Malformed Domain Result

  • Total Messages Validated with a Fail – Non-existent Domain Result

  • Total Messages Validated with a Fail – Not Permitted Result

  • Total Messages Validated with a Neutral Result

  • Total Messages Validated with a None Result

  • Total Messages Validated with a PermError Result

  • Total Messages Validated with a Pass Result

  • Total Messages Validated with a SoftFail result

  • Total Messages Validated with a TempError Result

  • Total Messages with no PRA

The Sender ID filter rejects or deletes mail only if the validation was successful with a status of Fail. In all other cases, the mail is transferred to Intelligent Message Filter for additional anti-spam processing, if Intelligent Message Filter has been enabled, or to the recipient’s mailbox.

Exchange Server 2003 SP2 provides a user interface for administering Sender ID. You’ll find the new Sender ID filter interface in Exchange System Manager by navigating to Global Settings, Message Delivery, Properties, and then to the Sender ID Filter tab.

You can configure Sender ID filter to handle incoming e-mail messages in three modes. Accept mode is the default configuration.

  • Delete   The e-mail message is deleted and no non-delivery report (NDR) is sent to the sender.

  • Reject   The e-mail message is rejected during the SMTP transaction.

  • Accept   The e-mail message is assigned a Sender ID status for additional anti-spam processing. 

You should understand that the Sender ID filter deletes or rejects mail only if a particular e-mail message has failed Sender ID verification. Therefore, the Sender ID filter deletes or rejects spoofed mail only. All other mail traffic is assigned a Sender ID status and passed along for additional anti-spam processing.

If the Sender ID filter is configured to work in the default Accept mode, the Sender ID just assigns the Sender ID status to the e-mail message, even with obvious spoofing. The Sender ID status is passed on to Intelligent Message Filter and triggers an appropriate modification of the spam confidence level (SCL) rating. If reputed sender does not have SPF records that are configured in DNS, the Sender ID filter does not reject mail from the sending organization.

The key to successful Sender ID implementation is correct filter configuration. I cannot stress enough how important it is to provide accurate configuration information about the messaging infrastructure. For Sender ID to function correctly, you must provide the IP address of every server in your organization that can route mail. That is why you must configure both the internal IP address range and the list of static IP addresses that handle inbound e-mail traffic from the Internet. If the e-mail servers that handle inbound traffic are in the internal IP address range, you do not have to provide list of static IP addresses.

You configure the Sender ID filter on the Message Delivery Properties page under Global Settings, but the Sender ID filter must be applied on the SMTP virtual server level. If you don’t enable the Sender ID filter on the appropriate SMTP Virtual Server Instance (VSI), it will not work.

For additional Sender ID Deployment information, see Sender ID Framework Deployment Overview.

For more information about publishing SPF records, see Sender ID Framework SPF Record Wizard.

For more information about Sender ID and additional resources, see Sender ID.

In Exchange Server 2003 SP2, Intelligent Message Filter comes preloaded with anti-phishing protection and supports a custom weights list.

In Exchange Server 2003 SP2, anti-phishing functionality is completely transparent to the end user. The anti-phishing technology is fully incorporated into the Intelligent Message Filter engine. All incoming mail is verified against phishing scams first and according to findings that correspond to a phishing confidence level (PCL) that is applied to each e-mail message. The PCL triggers assignment of the final SCL score.

Another new piece of functionality is custom weights list, also known as custom weighting. The custom weights list enables administrators to customize Intelligent Message Filter behavior based on text strings in an e-mail message body and headers. The custom weights list is made available in the form of an XML configuration file that is read by the Intelligent Message Filter upon initialization, and is subsequently reloaded whenever the XML configuration file changes. No user interface is associated with the custom weights list.

The custom weights list isn’t created during installation of Exchange Server 2003 SP2. Therefore, you must create it manually and put it in the default location for Intelligent Message Filter files: <path to Exchange server binary files>\MSCFv2\

In this path, <path to Exchange server binary files> refers to the location of the bin folder.

This is an example of the custom weights list file:

<?xml version="1.0" encoding="UTF-16"?>
<CustomWeightEntries xmlns="">
     <CustomWeightEntry Type="SUBJECT" Change="1" Text="foo1"/>
     <CustomWeightEntry Type="BODY" Change="-1" Text="foo2"/>
     <CustomWeightEntry Type="BODY" Change="5" Text="Special offer"/>
     <CustomWeightEntry Type="BODY" Change="-9" Text="Verlängertes Angebot"/>
     <CustomWeightEntry Type="BOTH" Change="MAX" Text="Offre spéciale"/>

The following table shows the values for each entry in the custom weights list.


Value Description

Type = BODY

Searches for a match in the displayed body of a message


Searches for a match in the displayed subject of a message

Type = BOTH

Searches for a match in both the subject and body of a message


Defines what the effect of a match is on the SCL score of a matched e-mail message. Change can be any integer value. If the phrase is matched, the change is added to the original SCL value. SCL values are normalized to a 0 to 9 range if they exceed that range because of custom weights. Change can also use the MIN or MAX keywords. When a phrase with the MIN keyword is matched, the message is assigned an SCL of 0 regardless of other weights. When a phrase with the MAX keyword is matched, the message is assigned an SCL of 9 regardless of other weights. When there are both MIN and MAX matches for one e-mail message, the message is assigned an SCL of 0.


Custom weighting can accept any Unicode phrase up to 1,000 characters.

These Exchange Server 2003 message hygiene and anti-spam enhancements enable administrators to create a layered, end-to-end anti-spam solution that better defends their Exchange organization against spam.