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.
Talkback
Sender-ID was not designed to prevent spam – but it is the first crucial step in the process of rebuilding trust related to the origin of email. Once Sender-ID is commonplace, accreditation services will become the next anti-spam frontier. This means that “known good” domains will be allowed to communicate freely, “known bad” domains will not be allowed to communicate at all.
Unknown (or new) domains would probably be considered guilty before proven innocent – hence possible requirements for new domains to sign up with accreditation services in order to “buy” a reputation.
Sender-ID also allows other good anti-spam techniques to work more effectively. Challenge-Response and Greylisting systems are very effective at handling unknown domains in a post Sender-ID world.
RSS will gradually mature and supplant bulk email – making life more and more difficult for spammers as email moves towards a one-to-one correspondence mechanism which is more easily managed through auto-whitelisting (amongst other things).
I see no real negatives in the anti-spam future (other than for anti-spam systems – which may be out of a job in a couple of years this all comes together).
Additionally, it appears that recent announcements within the IETF rule out XML records within DNS. This should reduce some of the concerns about DNS load and complexity.
I sent the following to Microsoft:
I saw a report about your proposals and wanted to add my comments. I work from home *a lot* and keep in touch with colleagues inside my organisation and contacts outside it by others. My organisation is a university and is effectively its own ISP; at home I use a commercial ISP and I have to send my email from home through their SMTP server. However, I can set everything up so that (a) it appears to recipients that I am at work and (b) they cannot easily see my personal email address. Indeed, that is what I am doing with this email. I appreciate that this is what spammers do, but I cannot be the only person doing something like this legitimately. I doubt that my organisation's IT unit would be happy to allow outside access to their SMTP servers. I would be disappointed if Email Caller ID were to be introduced in a way that prevented legitimate use such as mine.
Our Aloaha is supporting allready for several
month SPF1, SPF2, CallerID and SenderID.
Just check it out on www.aloaha.com
Modules like:
SPF1, SPF2, CallerID and SenderID
RBL, RWL
dont require any license since they are freeware.
Please note that most probably Aloaha is the only
true rejecting (traffic saving) AntiSPAM Solution
in the Windows World.
The best is that we are not limited to Microsoft Sink technology so we work together also with Notes, Imail, Proxy+ and more.
Thanks
FH