SMTP Authentication Update

 
 
By Larry Seltzer  |  Posted 2007-04-23 Print this article Print
 
 
 
 
 
 
 

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

Often 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


 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel