Vendor Attitudes

By Larry Seltzer  |  Posted 2004-03-02 Print this article Print

Meng Wong, the chief designer of the SPF spec, recently posted part of his discussions with Microsoft prior to Microsoft deciding to go it alone with Caller ID. The discussion basically deals with why they chose to use XML for their encoding as opposed to a more terse custom format like SPFs. From this and other sources Im sure Microsoft seriously considered all the possibilities before coming out with Caller ID. If you want to assume Microsoft is stupid, go right ahead (Meng Wong believes emphatically that they are not stupid), but I think if the next few months show that SPF and/or Domain Keys are better at authentication, Microsoft will either modify their own spec or buy into the others. Theyre not selling SMTP authentication, theyre selling products and services that are made better by SMTP authentication, and it behooves them to use the best method available.

At first glance, Caller ID and SPF have a lot in common, but theres an important and fundamental difference between them. Nothing to do with XML encoding; thats an interesting argument, but not all that important. The real difference is that SPF checks only the SMTP envelope address, whereas Caller ID reads the actual message in order to examine the headers.

The envelope is a prefix of sorts to an SMTP mail message. It just gives the address of who the message is from (the SMTP "MAIL FROM:" command) and who it is to (the "RCPT TO:" command). These are not the same addresses that the user sees in the From: and To: lines, but they do govern the address to which the mail server sends a "bounce" message in case the send fails.

One might ask: Dont spammers forge both the envelope sender and the From: address in the headers? They almost certainly do. But a phishing attacker could use a legitimate envelope address and false headers could slip through SPF. This was the main motivation for Microsoft going beyond SPFs envelope examination to full header analysis.

Its not something to do capriciously. All else being equal, SPF would be desirable because it should perform better. All it needs to check is the envelope, and it can reject messages without having to receive any of the headers or data. Caller ID and Domain Keys need to read it all.

But then Caller ID has the job of determining from the headers what they call the purported responsible address. I wont explain the algorithm for it here; see the spec itself, section 3.2 - Mapping a Message to a Purported Responsible Domain. Ive been assured by people who ought to know that this algorithm should work well, and by others who also ought to know that its not clear that it will. For the moment, Im confused. It looks to me like it certainly could work, but Ive been so suspicious for years of the truth of anything in message headers that I wonder if Caller ID can trust what it sees.

Its possible Microsoft has other motivations for digging into message headers, especially when you consider the policy framework they are building to manage this data. Perhaps there are more opportunities to sell development and management tools with Caller ID than with the alternative approaches. Clearly you would want the opportunity to do what Caller ID does if you could be sure it was reliable. But if it doesnt work well, well soon find out, since both spammers and customers will certainly beat on it as hard as they can over the next few months.

Next page: I Like Domain Keys

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