XML Developer Tip
(Receive this column in your inbox,
click Edit your Profile to subscribe.)
XML put to work in anti-spam standards
Those who have been following various attempts to specify e-mail anti-spoofing and authentication technologies, know that until recently Microsoft and the IETF were heading in similar but separate directions. As far back as February, 2004, lots of discussion was already underway about incompatibilities between Meng Weng Wong's work on the Sender Policy Framework (SPF) based e-mail authentication and Microsoft's e-mail Caller ID specification.
The crux of one of the primary differences between the two specifications, interestingly enough, was that the SPF specification called for text-based annotations to DNS MX (Mail transfer) records, whereas the Microsoft proposal called for XML-based markup for the same purpose. In each case, the intent was to provide access to e-mail policy rules for the server in question, to provide a means to authenticate e-mail traffic that purported to originate from a server, but also check to see if suspected spam has been authorized by its purported sender.
The disparity has now been resolved, and a new June, 2004, IETF draft specification has been crafted that resulted from joint efforts between Microsoft and the SPF team. The latest draft is entitled MTA Authentication Records in DNS, where MTA stands for "Mail Transfer Agent;" its author, Jim Lyon, works for Microsoft. In fact, as is the case for numerous other recent IETF drafts, XML is now part and parcel of the specification and the inner workings (in this case) of the e-mail policy statement and e-mail authentication mechanisms involved.
In a recent article on this topic, Robin Cover describes the processes involved as follows: "Given an e-mail message and an IP address from which it has been (or will be) received, the decision model tests whether the SMTP client at the host address authorized to send that e-mail message. Part of the authentication process involves finding the E-mail Policy Document for the purported responsible domain; this E-Mail Policy Document contains a description of a client authorization function with four arguments (the local-part of an e-mail address; a domain name called the 'original domain;' a domain name called the 'current domain;' an IP address, either IPv4 or IPv6)."
Furthermore, the specification is based around an XML infoset that defines the client authorization function, designed to determine if a domain owner is willing to assume responsibility for e-mail sent by some SMTP client or not. The XML infoset also defines a mail acceptance function, describes macro expansions performed on character data in some of its elements, and describes the algorithm that may be used to obtain the XML infoset. An XML Schema is also provided for this infoset as well.
The ultimate hope is that this will provide a mechanism to permit e-mail recipients to easily determine which e-mail messages are legitimate and valid, and which ones are spoofed. The theory, of course, is that spam normally falls in the latter category and that such checks can help to eliminate it. For everyone's sake, I hope they're right and that this XML-based approach provides some much-needed relief from "spam congestion." If so, XML may become a welcome part of our e-mail infrastructure.
Ed Tittel is a writer, trainer, and consultant based in Austin, TX, who writes and teaches on XML and related vocabularies and applications. E-mail Ed at etittel@lanw.com.
