Confessions of a Social Tools Architect
8 Mar
Life With Alacrity reports on the upcoming war over SMTP Authentication. As the SPAM wars continue, the leading mail vendors are all working to develop THEIR OWN standards for how the thwart the onslaught. Three major players have come forward: Yahoo! with Domain Keys, AOL with Sender Policy Framework, and Microsoft with its XML-based Caller-ID.
Christopher focuses on the Microsoft angle in his coverage.
As noted:
The big announcement of the week was that Microsoft will be be releasing their own spam solution, a Caller ID for email addresses, starting this summer in HotMail and in their mail servers. Basically the way this works is that every domain holder publishes inside their DNS records the IP addresses of any valid outbound email server. This information is stored using XML in a special signed format. After a mail is sent, the receiving system queries the DNS to confirm that the outbound server is not being spoofed.
[…]
Unfortunately, Microsoft’s Caller-ID proposal requires XML, which makes implementation much more complicated. It requires the entire email to be received by the server first, before looking up the DNS record, then validating a signature — all of which introduces more burdens on the mail server. Lastly, this XML may exceed the 512-character limit for DNS requests, which can cause DNS servers to send via TCP rather then UDP, which may introduces even more uncertainty.
Larry Seltzer of eWeek adds a more detailed analysis of all 3 and comments on the MS initiative:
It’s 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 doesn’t work well, we’ll soon find out, since both spammers and customers will certainly beat on it as hard as they can over the next few months.
Last week I questioned the use of “postage” on the client side as the sole solution. It seems that Microsoft’s Anti-SPAM program is attacking from both ends of the rope. Once again, the question still remains, How will these forces be brought to market in a uniform, meaningful manner when already there is infighting over the most appropriate technique?
5 Responses for "E-mail Caller-ID"
Parsing XML is not trivial and what’s more generating good XML is not trivial as well - you might think otherwise, but there are hidden complexities with encoding etc (especially with the unicode encodings that have the grammar elements encoded different than other encodings), and everyone that tried to write an RSS aggregator knows that XML is a bit fragile, and you end up with speciall rules for your every source to adjust to their special way of bad XML.
Since people are accustomed to treat email as the most reliable of electronic communication media - this fragility in the core of the email protocol can produce many problems. I believe that in fact those problems are one of the main Microsoft goals since they allready proved they are good fishers in muddy waters.
I agree that parsing XML can be a thorny issue, especially when dealing with user-generated content. However, I don’t know that the situation Microsoft is proposing is nearly as prone as say as generating an XHTML-compliant user comment or blog entry.
Efficiency can be gained by building custom parsers which could undoubtedly be compiled directly into the mail server or mail processing engine.
Definitely people are used to and rely on e-mail more and more these days. Delays and complications of that process would have negative reoercussions, to say the least. I’m not sure how long, however, that grumbling would persist if SPAM were effectively eliminated.
“Efficiency can be gained by building custom parsers which could undoubtedly be compiled directly into the mail server or mail processing engine.”
That is the core of the problem - what we’ll end up with will be standard defined by the implementation not the other way around - exactly the situtation Microsoft is pushing in all other areas.
I think you are missing the point. This is already presumably based on an open architecture.
The parser would be no different than any other engine that implements a standard. SMTP is a standard upon which hundreds of servers have been built. RSS is a standard upon which hundreds of parsers, readers, and aggregators have been built.
The standard is absolutely NOT something created from the implementation but something formed from the consensus of a wide enough group of people. Assuming that one standard can be reached may be too optimistic, but a couple that lead the way might suffice. POP and IMAP survived side by side, why wouldn’t methods for blocking SPAM?
The difference between XML and SMTP is that XML is really much more complicated (and what makes it even more evil is that the comlexity of XML is something hidden). What I am affraid of is that the MS developed software will not in fact accept all of their own defined standard - but rather will add some additional hidden assumptions about the messages. The complexity of XML makes it very easy to hide such additional requirements.
To prove my point about the complexity I’ve compared the sizes of the expat library and the postfix program with the postfix-util library, the result is that the whole postfix program and library is of the same size that the XML parser. So when you add XML parsing to an MTA you double it’s size. Of course that’s only the most easy way to compare the complexities, we can as well try to find a formal XML and SMTP grammar and compare their sizes, but I believe the result won’t be different.
Leave a reply