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 and Messaging Threats-Information Security Threats
Related Q&A from Michael Cobb
By performing ongoing risk assessments, organizations can keep their SSH vulnerabilities at a minimum and ensure their remote access foundation is ... Continue Reading
Sending sensitive information in attachments is inherently unsafe, and the main way to secure them -- encryption -- can be implemented inconsistently... Continue Reading
Spyware can steal mundane information, track a user's every move and everything in between. Read up on the types of spyware and how to best fix ... Continue Reading