Sender ID is a combination of Microsoft's Caller ID for Email and Sender Policy Framework. Sender ID and SPF differ in what problems they address. They validate separate header fields and work at different layers of the email system. Sender ID requires SPF in order to work, which makes the framework a higher level protocol.
As with most Microsoft-led initiatives, there has been some controversy. Depending on how Sender ID is implemented, the framework can be incompatible with existing specifications. Microsoft also holds patents on key parts of Sender ID, despite having just placed them under the Open Specification Promise, which can make the patents compatible with free and open source licenses. This should encourage the release of more products and services that use Sender ID technology. According to Microsoft, 5 million domains use Sender ID, meaning that around 36% of all legitimately sent email has been authenticated by the technology. Microsoft obviously uses it to check incoming mail to its own servers, as well as those of MSN and Hotmail. To implement Sender ID on Microsoft Exchange Server 2003 running Service Pack 2, configure the properties of the Message Delivery object under Global Settings.
There are other antispam technologies in development, including signing solutions. DomainKeys, created by Yahoo, uses public key cryptography as part of its authentication process. This technology will certainly prevent some types of attack, but deployment is not going to be as easy. Also, unlike Sender ID, DomainKeys cannot reject a message until the whole body has been received.
So how well does Sender ID stop spam? Well, it's easy to implement and is certainly a significant step toward countering spam and phishing attacks. Sender ID, however, does require everyone to create SPF records for their domains so that senders can be verified, and this process is one that cannot happen overnight, if at all. I don't believe there is a single solution to stopping all spam. Sender ID can certainly be used as a component of a multi-layered approach. Messages that fail checking, for example, can be rejected or subjected to a higher level of scrutiny than those that pass. Mail servers certainly still need to consider past behavior, traffic patterns, and sender reputation, as well as apply conventional content filters when determining whether to deliver mail to the recipient.
Dig deeper on Email Security Guidelines, Encryption and Appliances
Related Q&A from Michael Cobb
Expert Michael Cobb explains how password change frequency and reuse for third-party apps should be addressed in enterprise password policies.continue reading
Learn how a Web-based free spam-filtering service can secure email and prevent spam from attacking your enterprise.continue reading
Users in the enterprise may unknowingly be exposed to 'Gchat' security risks. Expert Michael Cobb discusses Internet application security best ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.