SMTP Authentication Update

Opinion: It's about 2 and a half years since the standards bodies threw up their hands and left SMTP authentication to the industry. Implementation progress has been slow but positive. And there have been some surprises.

They were heady days back in 2004 when the industry tried to reach consensus on a standard for SMTP authentication. The MARID (MTA Authentication Records In DNS) standards effort went down, partly in the flames of a political fight over patents with Microsoft, but the larger truth of the matter was that changes to heavily used standards like SMTP are bound to generate resistance from numerous sources, many of them with valid concerns.

But changes can come slowly, one site at a time over a period of several years. And sometimes they can be made more effectively when pushed by a big, strategic company than a standards body.

A little catchup on the terminology:

  • SPF (Sender Policy Framework) is a standard for authenticating messages by checking special records stored in the DNS for the domain that the message claims to be from. But it only checks the message envelope (the MAIL FROM statement in SMTP) and thus misses quite a bit of SMTP fraud.
  • SIDF (Sender ID Framework) is Microsofts approach to authenticating the entire message. The heart of it is the determination of a PRA (Purportedly Responsible Address) for the message and checking the domain of that address to see if the messagess sending agent is authorized. SIDF incorporates SPF as a first-stage test and stores further records in DNS in XML format.
  • DKIM (DomainKeys Identified Mail) is the merger of two similar standards from Yahoo and Cisco. It too uses DNS-based records to authenticate a messages sender as authorized for the domain of purported sender but uses a public key cryptography scheme for the authentication, removing the need to track actual IP addresses of servers.
While the MARID dust was still settling I dismissed the possibility of any real success in the market for SIDF. Throughout the relatively short process it became clear that everyone, even people at Microsoft, felt that, in the long term, a crypto-based solution was better for a variety of reasons. Some argued that the alternatives (mostly what became SIDF) were quicker and easier to implement and that they therefore were appropriate as a transitional technology. Microsoft did go ahead and implement SIDF in their Hotmail service and they have some industry support

/zimages/3/28571.gifOften the best way to thwart spamming and phishing is to take down the domain names involved in it, but this is a hard thing to do under current rules. Click here to read more.

But in the meantime , others decided to dive in to the DKIM pool and swim. There are some big mail providers on the list, Yahoo of course being the biggest and AOL is there too. Most of the others are actually software companies, important ones like Sendmail and IBM and qmail.org (I know, not really a company). Notice also a fair amount of overlap with the SIDF list. But how many of the smaller ISPs and hosting services support DKIM or SIDF? Not many I think.

SPF support is much more widespread. Setting up SPF is easy and its one of those standards that everyone loves and professes to admire, even though it does far less than most people think it does. Consider this Slashdot article and discussion about promotion of DMIM by PayPal. Of course, as usual, the Slashdot writeup overstates the actual claims in the article, but whats interesting is in the discussions how participants who claim to be administering mail servers for real organizations.

There is a general lack of understanding that SPF deals only with envelopes, a lack of understanding that all these systems are designed to work only at the MTA level, and a general assumption that SIDF is technically unsound (with no elaboration of course).

Next page: SIDF and the numbers