Exchange Server 2003 Service Pack 2 (SP2) delivers two new antispam features: Sender ID and Intelligent Message Filter (IMF). Both features are part of the Coordinated Spam Reduction Initiative announced by Microsoft more than a year ago.
Sender ID adds to Exchange Server 2003's antispam weaponry. Sender ID itself won't defeat spam, but it's certainly a key player that makes spamming harder. Given that the economics of spam favor the bad guys (i.e., low cost, high profit, and anonymity), anything that makes their lives more complicated can only be welcomed. So, let's look at how you can complicate some spammers' lives by implementing Sender ID into your organization. But first you need to know how Sender ID fits into Exchange 2003 SP2's overall defense against spam and how Sender ID works.
The Overall Defense
Exchange 2003 has a framework that supports many features designed to reduce the volume of spam. With SP2, the framework is extended to combat other disruptive email practices, such as spoofing and phishing. The framework is basically a set of filters that you can configure to act on different parts of messages (e.g., IP addresses, senders, recipients, contents) when those messages enter your Exchange system. For example, you can use connection filters to validate a connecting client's IP address against real-time block lists and sender filters to protect against spoofing. You can use recipient filters to protect against directory harvest attacks and to prohibit users from receiving external mail. Content filters can give you an indication of the likelihood that an email is malicious.
The filters are typically enabled on an SMTP virtual server that has been configured to handle inbound mail as the mail first enters an Exchange system. Most filters act only on anonymous SMTP connections because it's assumed that mail sent by authenticated users isn't intended to be malicious. SMTP connections between Exchange servers within an organization are always authenticated, so filters aren't invoked when mail travels through an organization en route to its final destination. To gain a deeper insight into the overall framework, you can read the blog at http://blogs.technet.com/exchange/archive/2005/ 07/18/407838.aspx.
Sender ID is a new filter in the framework. Sender ID provides a foundation for the reliable use of domain names in accreditation, reputation systems, and safe lists. It protects domain names by ensuring that mail purported to come from the domain has indeed been sent by a server that's authorized by that domain. In this regard, it's a great weapon against spoofing and phishing attacks.
How Sender ID Works
When an Exchange SMTP virtual server on which the Sender ID filter has been enabled engages in an SMTP conversation with another party to receive mail, it extracts the sending party's purported domain name and IP address. The Exchange SMTP virtual server checks this IP address against the list of authorized hosts that the domain administrator has published, thus proving authenticity and foiling the spoofer. Based on the result of this check, appropriate action can be taken.
To perform the check, Sender ID needs to obtain three pieces of information: an email domain, an IP address, and a list of authorized hosts for that email domain. After gathering this information, Sender ID takes the appropriate configured action.
Obtaining the email domain. Figure 1 shows a raw SMTP conversation that contains the envelope and content of an SMTP message received by an Exchange virtual server. The envelope (everything before the DATA command) contains the information needed to accomplish the transmission and delivery of the message. The content (everything after the DATA command) specifies the object to be delivered to the recipient. The content consists of header fields followed by the message body.
If you take a close look at Figure 1, you'll see multiple domain names—one in the envelope and several in the content header fields. Sender ID determines which domain name to use from the Purported Responsible Address (PRA). Using an algorithm, the PRA identifies the party that appears to have sent the message. Now you might think that this would merely equate to the MAIL FROM part of an incoming message, but that isn't necessarily the case. Because such tools as mail forwarders and mailing lists exist, the sending server in any SMTP conversation might not be associated with the same domain as the initial sending server.
For example, suppose that [email protected] sends a message to [email protected], with the latter having a forwarding address set to [email protected]. In this situation, two separate SMTP conversations must occur for the message to be delivered. In both conversations, the MAIL FROM part is [email protected]. However, there would be little point in the receiving server at digital.com validating whether the IP address of the connecting server is authorized to send mail from hp.com because the server will be from compaq.com.
Thus, you can't solely rely on the MAIL FROM part of a message when trying to determine the PRA. Instead, the receiving SMTP server must accept the whole message before any Sender ID check can be performed due to the fact that intermediaries in the delivery process stamp their participation through content headers. In the example just given, you would expect to see a Resent-From header that specifies [email protected] as an intermediary. However, it's entirely possible that a PRA can't be deduced from the message content because there's no guarantee that the necessary content headers will be present or in a suitable format from which a domain name can be extracted. Some SMTP gateways or filters even strip out part of the original SMTP headers to obscure the source server names.
From an efficiency point of view, it would be better to determine the PRA at the protocol level (i.e., before the DATA command) to avoid having to unnecessarily receive content that's then immediately rejected. This feat isn't possible today but should be in the future.
Obtaining the IP address. If there's a valid PRA, the check continues and Sender ID tries to obtain the IP address. You might assume that Sender ID merely has to check the IP address of the connecting server. Once again, it's not that straightforward. Many organizations don't expose their Exchange servers directly to the Internet. Instead, other servers in the demilitarized zone (DMZ) receive mail from the Internet, then pass it to Exchange gateway servers sitting behind the perimeter. Therefore, the connecting server is a trusted one and isn't the one Sender ID should check. Rather, Sender ID needs to check the IP address of the server that initially connected to the trusted server in the DMZ. To find this server, Sender ID looks at the content headers.
Obtaining the list of authorized hosts. Sender ID now has a domain name that the message is purported to be from and an IP address of a machine supposedly from that domain. Sender ID now needs to check whether this machine is indeed authorized to send mail for the domain in question. To do so, Sender ID uses DNS and Sender Policy Framework (SPF) records.
Organizations that want to publish the IP addresses of their authentic mail servers do so using DNS and SPF records. SPF records can simply list IP addresses or contain specific details, such as the organization doesn't have any outgoing mail servers. On the Sender ID home page (http://www.microsoft.com/senderid), you'll find a wizard that can help you generate an SPF record for your domain as well as check for the existence of SPF records for other domains. Registering your SPF records allows other organizations to detect when your domain name is being spoofed, thus also protecting your organization's reputation.
You can easily check whether an organization has published SPF records by using the Nslookup command. For example, if you run the command
nslookup -q=TXT gmail.com
you'll get a list of the SPF records for gmail.com.
Taking appropriate action. After Sender ID has obtained the domain name, IP address, and list of authorized hosts, it executes the DNS lookup, interprets the results, then takes the appropriate configured action. It's very important to stress here that the configured action will be taken only if Sender ID has actually managed to successfully perform the overall check and can categorically state whether the IP address is valid or invalid. If that isn't the case, the message will still be received as normal—albeit tagged with some information about why Sender ID couldn't perform the check satisfactorily. An overall check can be deemed to have failed for many reasons, ranging from DNS problems to badly configured or no SPF records. You can find a blog that describes the possible check results and how to expose the results in Outlook for forensic purposes at http://blogs.technet.com/exchange/archive/2005/10/13/412487.aspx.
If a message fails the Sender ID check (i.e., the domain couldn't be determined, the IP address couldn't be determined, or the IP address wasn't valid), Sender ID takes action. The action taken depends whether you configure Sender ID to run in reject, delete, or accept mode. In reject mode, the message isn't accepted and a nondelivery report (NDR) is sent to the client. In delete mode, the message is accepted but then deleted, with no NDR returned to the sender. In accept mode, the result of the Sender ID check is stamped onto the message, then the message continues to the next filter in the framework. That way, subsequent filters can take action based on the results.
For example, a message's Spam Confidence Level (SCL) is influenced by the result of the Sender ID check when content filtering is enabled through IMF. The SCLs of messages that failed the check are set higher because these messages are much more likely to be spoofed messages. The SCL affects whether messages remain in a user's Inbox, are automatically moved to a Junk Mail folder, or are deleted. Like the Sender ID check results, SCLs can be exposed in Outlook. For more information about exposing SCLs, see the blog at http://blogs.technet.com/exchange/archive/2004/05/26/142607.aspx.
Configuring the Sender ID Filter
As with all the filters in the framework, you first configure the Sender ID filter's operation at a global level, then apply filters to the necessary SMTP virtual servers. You use the properties of the Global Settings/Message Delivery object in Exchange System Manager (ESM) to configure all the filters.
To configure the filter at the global level, open ESM, right-click Message Delivery under Global Settings, then select Properties. In the Message Delivery Properties dialog box that appears, you need to configure settings on the Sender ID Filtering and General tabs.
On the Sender ID Filtering tab, you simply set the desired mode (i.e., reject, delete, or accept) for failed checks. On the General tab, which Figure 2 shows, you need to configure the Perimeter IP List and Internal IP Range Configuration settings. These settings influence how the connecting IP address is determined. Click Add to display the dialog box in which you need to specify all the IP addresses of those servers in your organization that you trust and that will be connecting to any Exchange servers that have the Sender ID filter enabled. You should include the IP address of any sort of SMTP relay host within your organization, such as SMTP-based content-inspection systems. Any IP addresses listed here are discarded as the filters attempt to determine the original connecting IP address through the message's content headers.
After you've configured the global settings, you can configure the Sender ID filter on the desired SMTP virtual servers in your organization. This option is well hidden. You access it by right-clicking the desired SMTP virtual server in ESM, selecting Properties, clicking the Advanced button, then clicking the Edit button. In the Identification dialog box that's displayed, select the Apply Sender ID Filter check box, as Figure 3 shows. For more information about how to configure the global-and server-level settings for Sender ID, see the Microsoft article "New Weapons In The Fight Against Spam" at http://www.microsoft.com/technet/technetmag/issues/2006/01/newweapons/default.aspx.
To monitor Sender ID operations, you can use a performance object called MSExchange Sender ID. With this object, you can track the number of DNS lookups performed, the number of messages processed by Sender ID, and the various Sender ID check results. Note that this performance object might not appear until you've enabled the filter and sent your first message.
Complicate Spammers' Lives
Microsoft's Coordinated Spam Reduction Initiative has now started to deliver. Sender ID and IMF are now available for you to use in the fight against spam. Although Sender ID doesn't prevent spam, it certainly can help you identify spoofing and phishing scams. It also makes it more difficult for spammers to apply their trade. I urge all of you to go forth and register your SPF records!
