Microsoft proposes Sender ID to jam spam
Microsoft announced last week that it has combined its Caller ID proposal with the Sender Policy Framework (SPF). It has submitted the merger -- called Sender ID -- to the Internet Engineering Task Force (IETF) for approval.
"Sender ID will verify that each email message originates from the Internet domain it claims to come from based on the sender's server IP address," Microsoft claimed in a statement.
"Eliminating domain spoofing will help legitimate senders protect their domain names and reputations, and help recipients more effectively identify and filter junk e-mail."
Caller ID and SPF were both created to try and prevent domain spoofing. The spoofing takes advantage of a flaw in the Simple Mail Transfer Protocol (STMP) that makes it possible to label an email with a fake address. It's used by spammers to disguise the origin of their junk mail, and fraudsters to pretend that their emails come from genuine financial institutions.
With Caller ID, announced in February 2004, Microsoft proposed that the IP addresses of outgoing mail servers should be added in XML to the domain name server (DNS). This would allow the recipients of email to see whether the IP addresses of the message they received tallies with the domain that it purports to have been sent from. If it doesn't, the mail could be treated as suspicious and dropped.
SPF, which preceded Microsoft's own efforts, took another approach, putting authentication at the start of the process of sending and receiving email -- the simple message transport protocol (SMTP). Like Caller ID, SPF also used the DNS to provide information about servers that send mail on behalf of a particular domain. With SPF, when a mail server gets an incoming message, it looks up the sender's domain to get the SPF record, and checks whether the sending server is in the permitted list. If not, the mail is rejected as a forgery.
The key difference between SPF and Caller ID was that the former attempted to established the authenticity of an email before it was sent, while the latter would examine the message once it had been received.
Sender ID appears to combine the best of both worlds. It will allow some messages to be blocked before they are even sent (using SPF's SMTP-based interrogation), and will also check the header of emails that have been received.
Sender ID also includes backwards compatibility with SPF's text-based records, which means the thousands of domains that have already published SPF records don't have to change to comply with the new system.
However, some experts aren't convinced that Sender ID will be a the final answer to malicious and opportunistic use of the Internet.
John Regnault, head of security technologies at BT Exact, believes that Sender ID will dent the level of phishing attacks on the Internet, but expects that some fraudsters will soon find a way of beating it.
"They'll probably get round it," Regnault predicted, adding that organised criminals have turned Internet hacking into an "industrialised" process.
He suggested that even with Sender ID, it might be possible to obtain a domain name through a stolen credit card, rent space on a server with a legitimate DNS entry, and launch phishing attacks over several days before anyone took action.
Regnault is also concerned about the burden that Sender ID will place on the DNS through its use of XML.
"The more complexity you add to an IT system, the more you open it to abuse," Regnault said. He pointed to last week's attacks on Akamai -- which blocked access to major sites such as Apple, Google, Microsoft and Yahoo -- to show that DNS is already vulnerable.
Microsoft says that it is still interested in hearing the views of interested parties regarding Sender ID, at senderid@microsoft.com.
More details of Sender ID can be seen here (a pdf file).
ZDNet UK's Jonathan Bennett contributed to this report.