Exchange Server 2007

Fighting Spam and Phishing with Sender ID

Craig Spiezle and Alexander Nikolayev

At a Glance:

• Sender ID basics
• Configuring Sender ID in Exchange Server
• Benefits of authentication

Many identification and filtering technologies have been developed in response to the growing threat of spam. To be effective, they rely on asking certain questions about each e-mail message, such

as who sent it. Unfortunately, the fundamental question of who sent the message is not always easy to answer. E-mail is typically sent over the Internet without any authentication of the sender or the computers acting on the sender's behalf. The fact is, sending an e-mail message while pretending to be someone else is simple, and there is no automated method of detecting spoofed messages.

Simple Mail Transfer Protocol (SMTP), which is used to send and receive e-mail, was never designed to verify the sender of an e-mail message. With this technological loophole, any name and address can be inserted as the sender. As a result, content-filtering or anti-spam measures cannot rely on header information alone to ensure that messages actually come from where they say they do.

E-mail authentication specifically addresses this loophole. With authentication, both sending and receiving e-mail systems validate that messages come from the domains they claim to come from. This makes it easier for organizations to filter junk mail effectively, yet also ensure that legitimate e-mail reaches its intended recipients.

Today, there are two royalty-free approaches to e-mail authentication: the Sender ID Framework (SIDF) and DomainKeys Identified Mail (DKIM). SIDF is an Internet Protocol (IP)-based solution created from the merger of the Sender Policy Framework (SPF) and Microsoft Caller ID for E-Mail. In April 2006, the Internet Engineering Task Force (IETF) published the Sender ID specifications as RFCs 4405-4408. A coalition of industry and business stakeholders, including Microsoft, recommends the deployment of SIDF based on factors including business and technical value, stability, maturity, ease of deployment, minimal impact on outbound or inbound performance, and interoperability with the e-mail ecosystem for ISPs and enterprise environments.

DKIM is the merger of Yahoo! DomainKeys and Cisco Systems Inc.'s Identified Internet Mail (IIM) specifications. In January 2006, the IETF approved the creation of a DKIM working group and the specification is currently under IETF review.

While there is no perfect solution to counter spam, SIDF represents a significant industry initiative to counter spoofed domains. As a result, it is a key component of reducing spam and phishing attacks and increasing trust and confidence online. Organizations around the world are adopting SIDF at a rapid rate. Today more than 5.5 million companies and domain holders have published SPF records and more than 600 million users are protected by SIDF. Currently, over a third of the world's daily e-mail volume is now authenticated and SIDF-compliant.

The development and worldwide adoption of SIDF would not be possible without the contribution and support of many organizations and companies including AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign, and others.

Understanding Sender ID

Some industry surveys indicate that over 95 percent of phishing scams come from spoofed domains and have spoofed sender e-mail addresses. This is where SIDF makes a huge difference with regard to anti-spam processing. By itself, SIDF will not solve the problem of spam, but it greatly contributes to minimizing the consequences of spam and phishing attacks. SIDF does not prevent junk e-mail from being sent. However, it does make junk e-mail much easier to detect. The framework helps e-mail senders protect their domain names, their reputations, and their brands. It provides a solid basis for making filtering decisions based on the reputation and e-mail behavior of the sender.

Sender ID seeks to verify that every e-mail message originates from the Internet domain from which it claims to have been sent. This is accomplished by checking the address of the server sending the e-mail against a registered list of servers that the domain owner has authorized to send e-mail. Verification is performed automatically by the Internet service provider (ISP) or the recipient's mail server before the message is delivered to the user's Inbox.

Note that Sender ID, or any other authentication mechanism, does not replace content filtering systems. Neither SIDF nor DKIM scans actual message content. Instead, authentication notifies the inbound mail system of whether the message can be validated as coming from the claimed sender. Because most spam and phishing exploits do not actually come from the domain shown, this approach can help automatically identify these messages and separate them from the incoming mail stream.

Within SIDF, the SPF record provides a simple text record of all outbound mail servers associated with a domain, along with their respective IP addresses. An organization publishes the SPF record to its DNS server zone file, which is then checked by recipient mail servers. Setting up an SPF record is fast, easy, and free. The Sender ID Framework SPF Record Wizard provides a step-by-step process for surveying a domain's mail servers and creating customized records ready for posting. (Details on publishing an SPF record are available at microsoft.com/senderid. The wizard can be accessed directly at microsoft.com/senderid/wizard.)

The receiving SMTP mail server pings the domain's zone file in the DNS for the existence of an SPF record. Once found, the IP address of the sending server is checked against the IP addresses listed. If there's a match, the message is validated as authentic. If, on the other hand, the SPF record on the sender's domain does not match the IP address the message came from, it fails, resulting in a negative score and potential placement in the junk mail folder. Figure 1 shows this process.

Figure 1** Checking SPF Records for Incoming Messages **(Click the image for a larger view)

After the message has been tagged, SIDF enables the recipient mail server to analyze the message based on past behaviors, the reputation of the sender, its content, and other criteria that can be defined as needed. This ability provides extra safeguards. For example, spammers can register look-alike domains and published SPF records to deceive a user and receiving network into thinking the mail is from a legitimate sender. And even though the e-mail message may pass the authentication check, the sender's reputation as a spammer is enough to block, junk, or delete the message.

Sender ID Deployment Options

Outbound e-mail authentication via SIDF does not require any infrastructure changes or software updates and is not specific to client or server software. However, organizations that want to incorporate inbound authentication to protect their company and employees will need to update their inbound systems and Message Transfer Agent (MTA), and deploy software or an appliance that supports SIDF. The majority of leading commercial and open-source MTAs and anti-spam vendors, including Microsoft® Exchange Server and Exchange Hosted Filtering, offer integrated solutions.

Microsoft has integrated SIDF into all of its messaging products, including Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express, and the Office Outlook messaging and collaboration clients.

Even Microsoft is not exempt from receiving spam, however. The average daily incoming traffic at Microsoft is approximately 15 million messages, and during recent spam attacks we've seen as much as two to four times that volume. In such an environment, the route to successful spam protection lies in vigilant implementation of the technologies available.

Microsoft is running an internal Exchange Server anti-spam solution based on the Sender ID filter in Exchange Server 2003 and the Sender ID agent in Exchange Server 2007. In both versions of Exchange Server, the Sender ID status is based on the evaluation of the Sender ID record located on the corresponding DNS servers. The actual domain is determined by examining the RFC 2822 message headers in the following priority:

1. Resent-Sender
2. Resent-From
3. Sender
4. From

The sender's domain (or the entity most recently responsible for injecting a message into the messaging stream, because e-mail systems can legitimately forward mail on behalf of other mail servers) is determined by locating the first definition of the headers just mentioned in the order defined. If none of these headers are found, SIDF will use the SMTP RFC 2821 MAIL FROM value.

Configuring Sender ID

In Exchange Server 2007, the Sender ID agent can be enabled on servers that have the Edge Transport role installed. If the Sender ID agent is enabled, it will filter messages that are coming through the receive connectors-all incoming (from external sources) non-authenticated traffic will be subject to Sender ID processing. In Exchange Server 2003, the Sender ID status is persisted server to server in the EXCH50 blob; in Exchange Server 2007 it has also been added to the message metadata. At the final destination both are converted to a MAPI property for future client consumption.

The Sender ID Filtering configuration in Exchange Server 2003, available under the Message Delivery Properties, consists only of specifying how Exchange Server handles failed validation.

To enable Sender ID in Exchange Server 2007, just open the Exchange Management Console for a server with the Edge Transport role configured, select the Anti-spam tab, then Sender ID, and in the Actions pane click Enable or Disable to toggle the Sender ID agent as shown in Figure 2. Additionally, you can use the Exchange Management Shell to enable or disable Sender ID as shown in Figure 3.

Figure 2** Exchange Management Console Controls for the Sender ID Agent in Exchange Server 2007 **(Click the image for a larger view)

Figure 3** Enabling Sender ID using the Exchange Management Shell **(Click the image for a larger view)

The Sender ID Properties dialog box will reflect the status of the agent, either enabled or disabled. The Action tab provides very similar options to those available in Exchange Server 2003 (see Figure 4).

Figure 4** Sender ID Agent Action Properties in Exhange Server 2007 **(Click the image for a larger view)

In terms of Sender ID implementation and functionality, there is no major difference between Exchange Server 2003 and Exchange Server 2007 and both Sender ID filter (in Exchange Server 2003) and Sender ID agent (in Exchange Server 2007) use the same underlying algorithm for extraction and verification. The range of possible actions is also the same: Delete Message (silent delete), Reject Message (500-level SMTP protocol response), and Stamp the message with the Sender ID result and continue processing. This latter option is the Default action in both versions of Exchange Server.

In Exchange Server 2007, both FAIL and TempError status codes can trigger a Reject Message action (in Exchange Server 2003 only a FAIL status code can trigger this action). The Sender ID agent needs to be explicitly configured to trigger the Reject Message action on messages with a TempError status code because, by default, those messages will be accepted into the system, stamped with Sender ID result, and then processed.

The configuration option for this is not exposed through the graphical user interface so you must use the Exchange Management Shell to configure Sender ID actions for TempError status code. For example, to force the Sender ID agent to reject messages with a TempError status code, run the following Sender ID agent cmdlet:

Set-SenderIDConfig -TempErrorAction Reject

The range of Sender ID status results and possible actions in Exchange Server 2007 is similar to that of Exchange Server 2003 Sender ID filter and is shown in Figure 5.

Figure 5 Sender ID Status and Actions in Exchange Server 2007

Exchange (if configured to do so) will delete only messages that failed Sender ID verification. No other results will trigger message deletion. Incoming messages that resulted in Neutral, None, SoftFail, TempError, or PermError status assignment will be appropriately stamped and passed on for further anti-spam verification. In some cases, when the message is hopelessly malformed and the FROM IP address is missing, the Sender ID status cannot be stamped on the message. In this situation the message is not discarded or rejected. Rather, it will be passed on for further processing without the Sender ID status set and an appropriate event will be logged to raise awareness.

In Exchange Server 2007 it is easy to define sender domains and Exchange Server recipients that should be excluded from Sender ID verification. Again, this configuration option is available through the Exchange Management Shell only. For example, to exclude domain contoso.com from Sender ID filtering, run the following command:

Set-SenderIDConfig -BypassedSenderDomains contoso.com

Similarly, to exclude messages sent to specified Exchange Server recipients from Sender ID filtering, run the following command:

Set-SenderIDConfig -BypassedRecipients user@contoso.com

In Exchange Server 2007, Sender ID configuration values set via Exchange Management Shell cmdlets but not available through the graphical user interface can be easily obtained by running the Get-SenderIDConfig command in the Exchange Management Shell as shown in Figure 6.

Figure 6** Sender ID Configuration cmdlets **(Click the image for a larger view)

The Exchange Management Shell can be used for quick manual verification of the IP address and the corresponding domain name. To check the Sender ID status, run the following command:

Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>

If the domain does not exist, you will see a result similar to Figure 7.

Figure 7** Verify Sender ID Status of an Address **(Click the image for a larger view)

Benefits of Sender ID

Aside from its obvious benefits in authenticating e-mail messages and reducing the amount of spam users receive, SIDF as a protocol offers other advantages. During its development, Microsoft focused on several key goals, including performance, cost, deployment and scalability, and interoperability.

SIDF first authenticates an e-mail sender and allows for the application of the sender's reputation score. As a result, it has the potential to significantly decrease spam and spoofed e-mail messages, and improve deliverability of legitimate e-mail from known and trusted senders. Creating an SPF record is free, so any organization that wants to be SIDF-compliant can do so easily. Organizations wishing to comply with the provisions of a new standard should be able to do so. With SIDF, compliance is as easy as publishing an SPF record.

SIDF has been developed to operate within existing software wherever possible. It can be used with a broad range of e-mail architectures and client and server software. To be effective, any authentication service must be able to meet the needs of the largest ISPs as easily as the smallest home mail server. SIDF can support from one e-mail server to thousands, plus those who outsource their e-mail servers to another organization.

On April 18-19 2007, Microsoft and an industry consortium of over 30 organizations and partners are hosting the Authentication & Online Identity Summit in Boston, MA. This two-day program will review case studies and offer a technical review of Sender ID, detailing the business value of e-mail authentication. For more information, visit aotalliance.org/summit2007. In addition, for information including tools and resources, you can visit microsoft.com/senderid and microsoft.com/exchange.

Craig Spiezle is the Director of Technology Strategy and Planning for Windows Live Safety at Microsoft. As the Product Manager for e-mail authentication, Craig has been a driving force in bringing Sender ID to the industry. Starting at Microsoft in 1992, Craig has held several management positions including International marketing, product support strategies, OEM, and emerging market development.

Alexander Nikolayev is the Program Manager at Microsoft in charge of server-side protocols, Transport Core, and anti-spam components for Exchange Server and Windows Server. He holds an MBA from the University of Mary. Read Alexander's posts on the Exchange team blog at blogs.technet.com/exchange.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.