|
Championed by Microsoft, the Sender ID Framework is an email authentication technology that has been around for a couple of years. It aims to verify a sender's identity, checking that each email message originates from the Internet domain it claims to have been sent from. This tactic addresses spammers and phishers who forge or spoof the sender's address on email messages. Sender ID lets the receiving mail servers determine whether a sending mail host is authorized to send email for a particular domain. Sender ID matches the address of the sender server with the SPF (Sender Policy Framework) record, published in the sender domain's DNS records. An Internet service provider (ISP) automatically performs this verification before an email is actually delivered to a user.
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.
More information:
Learn why simple antispam filters alone cannot solve the image spam problem.
Read how to verify OpenPGP users.
|
