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.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
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.