Sender ID and FUD

Microsoft has been talking about the Sender ID standard for a while. But two recent Microsoft announcements triggered a sudden resurgence of interest in the standard. First, earlier this year, Microsoft announced that Sender ID support will be included in Exchange 2003 Service Pack 2 (SP2); Microsoft will use Sender Policy Framework (SPF) data as input to the Exchange Intelligent Message Filter. This announcement is great news but is primarily of interest only to Exchange administrators.

What really stirred the Sender ID pot was Microsoft's June 2005 announcement that the company will start using Sender ID to filter MSN Hotmail messages. The immediate reaction was driven in large part by a News.com article (see the first URL below) and a post on Slashdot that cited it (see the second URL below) claiming that Hotmail will simply junk any messages sent from a domain that doesn't have a valid Sender ID record. As you might expect, this claim provoked a great deal of sound and fury from Microsoft opponents. Too bad it isn't true.
http://news.com.com/Microsoft+pushes+spam-filtering+technology/2100-7355_3-5758365.html?tag=nefd.top?headline=Microsoft~pushes~spam-filtering~technology
http://it.slashdot.org/it/05/06/23/1354232.shtml?tid=109

The debate continues about whether Sender ID is a useful antispam measure, but that question isn't central to this discussion. Why? Because Microsoft isn't going to junk a Hotmail message solely on the basis of its Sender ID status. In the June press announcement, Craig Spiezle, a director in the Technology Care and Safety group at Microsoft, was quite unambiguous about this point: "Hotmail is not planning to junk or delete legitimate email that our customers want to receive solely because the sending domain does not have an SPF record. Our use of email authentication is to aid the accuracy of our email filtering, but it remains only one of many factors that our filters examine when evaluating incoming e-mail." He went on to say that as Sender ID and SPF become more common, messages sent from domains that don't use these records will come under greater scrutiny--and that's as it should be. For now, however, messages that come from domains without Sender ID records show up with a special "safety bar" in the Hotmail interface.

Sender ID and SPF aren't antispam tools; they're tools that help you determine whether an email message is from the domain it claims to be from--nothing more. They're great for protecting against phishing, and they help prevent spam that falsely claims to be from someone other than the real sender. However, they don't stand alone, which is why Microsoft's announcements make sense. Sender ID will be integrated with existing antispam filtering methods on both Hotmail and Exchange. You can think of Sender ID as an additional filtering mechanism that sits alongside sender and recipient addressing, message content, message header validity, and other time-tested antispam methods.

Sender ID and SPF do have their faults. In particular, Sender ID breaks forwarding services, which isn't optimal and might be a problem if you use one of those services. Most Internet email users, however, don't. (The Forbes article "Microsoft, Yahoo! Fight Spam--Sort Of"—see the URL below--describes some drawbacks of other sender authentication systems, such as Yahoo!'s DomainKeys.)
http://www.forbes.com/intelligentinfrastructure/2005/07/14/microsoft-yahoo-spam-cx_fr_0714spam.html

What should you do? First, create a Sender ID record for your domain. I discussed how to do this in a column earlier this year, but Microsoft has posted a Web-based Sender ID wizard (see the URL below) that trivializes that process. The wizard helps build the "fax machine effect" (i.e., the more Sender ID records that exist for legitimate domains, the more useful they'll be for detecting bogus messages). Second, send a message from your domain to Port25 Solutions' automated test tool at [email protected]. You'll receive a response message that spells out for you what your Sender ID record is telling the world; you can use this information to fine-tune your record.
http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx

For the somewhat longer term, make your deployment plans for Exchange 2003 SP2 so that you can start taking advantage of Sender ID filtering as a component of your antispam process. In my opinion, any solution that helps cut down on phishing is worth examining for deployment, even if it isn't perfect.