Microsoft Could Do More: SMTP Authentication

By Larry Seltzer  |  Posted 2007-11-26 Print this article Print

Opinion: There was a time when Microsoft's own solutions could have been a part of a systemic solution to the problems in e-mail. Those times are past, and they need to join in with the rest of the industry.

"Not Invented Here" is an unfortunate syndrome that affects many a company. I think NIH is the unfortunate driver behind Microsofts policies on SMTP authentication. Were all suffering as a result. This is the second in my "Microsoft Could Do More" series. Microsoft has done more than most with respect to SMTP authentication, which is an effort to let mail recipients check whether mail from a specific domain actually was sent from that domain.

Several years ago, Microsoft released an ambitious and complicated standard for SMTP authentication called Sender ID and tried to have it standardized through the Internet Engineering Task Force working group MARID (MTA Authentication Records in DNS). The effort failed mostly because Microsoft insisted on asserting intellectual property rights in Sender ID, even though they offered a free license to all who asked.

What are the different standards involved in SMTP authentication? Click here for a recent discussion.

From the rubble of the MARID effort rose DomainKeys, a SMTP authentication effort that had been ongoing but generally considered as having longer to get to market than Sender ID. Initially developed by Yahoo, DomainKeys was merged eventually with Ciscos Identified Internet Mail standard to form DKIM, or DomainKeys Identified Mail. DKIM is now what Sender ID wanted to be, an IETF proposed standard. It has the backing of many important entities, including Google.

From the same rubble, Sender ID was reduced from a full message authentication protocol to a new version of SPF (Sender Policy Framework), a protocol that does much less. Microsoft has gone on to promote Sender ID, although not with much energy.

At one point during the MARID debates, someone from Microsoft acknowledged that eventually a solution to SMTP authentication based on public key cryptography, a clear allusion to DomainKeys, would be preferable, but that Sender ID was the better interim solution. Perhaps there was a time when this was true, but that ship has sailed, and DKIM is in harbor and taking on passengers.

Microsoft never saw Sender ID as a revenue stream, and even as a competitive tool, its hardly a winner. They dont need to abandon it in order to include support for DKIM; as far as I know, the two systems are actually somewhat complementary. But DKIM is the more important one, and the one with the bigger upside.

Detractors like to point out that SMTP authentication, including DKIM, only authenticate; they dont tell you that the sender is desirable or even benign. (Microsoft isnt among the cheap attackers.) Of course this is correct, and authentication requires reputation and accreditation systems in order to fulfill its promise. But authentication doesnt just require these solutions, it enables them. You cant have meaningful reputation systems without authentication.

Whatever the solution is to the problems in the Internet mail system, they have to begin with authentication. Its clear that filtering is never going to be a solution. I really do think that an e-mail system with real authentication available could be far cleaner than todays systems.

Its also clear that the only real game in town for SMTP authentication is DKIM. It may not be Microsofts solution, but theres nothing anti-Microsoft about it, and it serves goals that Microsoft seeks. Microsoft should do their customers a favor and join in with the DKIM effort, and do so wholeheartedly.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at Security Center Editor Larry Seltzers blog Cheap Hack More from Larry Seltzer
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