For the past several months a standards group of the Internet Engineering Task Force named MTA Authorization Records in DNS, or MARID, has labored to form a proposed standard for SMTP authentication. That effort will move along one step this week at the 60th IETF meeting in San Diego.
Based originally on SPF (Sender Policy Framework), an effort driven by Meng Weng Wong, co-founder and CTO of Pobox.com, it has grown in scope to include many other functions, most controversially the authentication of mail header data. The result is a set of documents defining Sender ID, which the IETF will consider for advancement in the standards process.
The aim of SMTP authentication is to impose some rules on an Internet e-mail system that heretofore, when an Internet e-mail message is sent purporting to come from a particular address, there is no verification process to confirm that it did come from that address. Spammers, phishers and virus authors know this full well and use the fact to disguise the source of their messages.
Sender ID does not pretend to be a full anti-spam solution, just a necessary part of one. Meng Wong describes a framework called Aspen under which spam is addressed by authentication, accreditation and reputation. Accreditation, according to Wong, “lets third parties vouch for senders with whom they have a prior relationship.” Reputation is more of a ratings system for senders and accreditors.
Many companies, including Brightmail (recently purchased by Symantec), have entered the reputation service business. Sender ID directly enables authentication and accreditation and touches on reputation. It is also backward-compatible with SPF.
SPF and almost all the many variants discussed in the working group set rules for the authorization to send mail by putting new records in the domains DNS (hence the name MARID). Understanding the specifications and the arguments between participants in the standards process often requires expert understanding of DNS jargon.
Next page: The Microsoft bogeyman.
The Microsoft Bogeyman
Nothing got members of the working group more upset and caused the chair to threaten banishment more than complaints about Microsofts involvement in the drafting of the specification. Midway through the process, Microsoft and Meng Wong negotiated a convergence of SPF with Microsofts Caller ID for E-mail specification.
While many participants objected to working with Microsoft simply on principle, the biggest objection had to do with intellectual property rights. Microsofts contributions to Sender ID are based on their Caller ID for E-mail specification, and they make unspecified patent claims on this technology. Many participants and outsiders, including free software luminary Richard Stallman, spoke up in objection to the Microsoft license for this technology, which effectively prohibits its inclusion in programs using any major open-source license.
The IETF has no formal objection to standards based on patented technology, but there is a part of the standardization process that deals specifically with intellectual property issues. Some have observed that the Microsoft patents are probably defensive in nature (against so-called “patent trolls”) and asserted that the real threat is not the existence of patents, but a license to that patent that is too restrictive.
The working group has issued a request to Microsoft to clarify its position with respect to its intellectual property claims. Microsoft employees on the working group say they are working on their response, but that it needs the appropriate approvals, which have not yet been completed.
Andy Newton, one of two chairs of the IETF MARID working group, says of the licensing issue that “it is the working group that decides if it can abide by the terms of any license for any claimed IPR within any document it wishes to standardize. In short, the working group will decide the issue.”
Next page: DRIP, CSV, DMP, RMX, FSV, DVP, SPF, DK, C-ID
DRIP, CSV, DMP, RMX,
FSV, DVP, SPF, DK, C-ID”>
SPF was not the first attempt to create a DNS-based SMTP authentication scheme. Authors of and advocates for alternative plans have been vocal in the working group, and many continue to argue vehemently for their side and against Sender-ID.
There are two parts to an e-mail message relevant to the groups discussions, the envelope which is described by RFC 2821 and the message data, including the headers, defined by RFC 2822. SPF and many of the other proposals only check the addresses found in the envelope, whereas Caller ID and Sender ID also check the RFC 2822 contents.
With the inclusion of Caller ID, Sender ID offers a variety of authentication and related functions to the site administrator. The major ISPs, such as Microsoft, place great value on authentication of the RFC 2822 data in order to fight “phishing” attacks.
Because the domain presented in the envelope is not the one the user sees when reading an e-mail message, RFC 2821 schemes dont prevent phishing. A message could pass muster with SPF Classic as being sent from spammer-throwaway9942.com while having a displayed From: address of support@citibank.com. Sender ID determines the PRA (Purported Responsible Address), which is the address responsible for sending the message. This isnt necessarily the From: address. In the case of mailing lists, for example, another server could be responsible, and Sender ID defines a protocol for determining the correct one. The PRA algorithm is itself the subject of controversy, and many contend it cannot be accurate in all cases.
One of the ancillary standards proposed is called SUBMITTER, an extension to RFC 2821 that provides a mechanism for proper handling of forwarded mail. Imagine a user a@sender-domain.com sends a message to b@forwarding-service.com. Mail sent to b@forwarding-service.com is forwarded to c@recipient-domain.com. The recipient-domain.com mail server sees the message come in with MAIL FROM: a@sender-domain.com, but in fact it is sent from b@forwarding-service.com. By adding the submitter extension to the SMTP command (MAIL FROM:a@sender-domain.com SUBMITTER=b@forwarding-service.com) the mail server can determine the PRA correctly.
CSV (Client SMTP Validation) checks if the IP address of the sender is permitted to send for the domain. Sender ID does this, although some members of the working group think this is all it should do. This is the approach of John Leslie, who argues that we need something really lightweight, lighter than SPF.
John Levine, author of “The Internet for Dummies,” agrees: “Personally I think even SPF Classic is too complex.” But the XML-based caller ID portions of Sender ID are what really turn Levine off. “Extensibility sounds nice in principle, but the reality is that each time you add something new, you also introduce compatibility issues with everyone else who doesnt have your new feature or who has different new features of their own. But thats not going to work in the e-mail world.” Levine is not alone in this view, but the XML-based Sender ID was moved along in no small part because of the extensibility it allows.
SPF Classic, as its author calls the old SPF, has a certain amount of extensibility in it, but its awkward. XML was designed for extensibility. And Verisigns Phillip Hallam-Baker points out that XML development tools and libraries are ubiquitous and powerful. Levine sees XML turning grotesque; Hallam-Baker sees it as leading to elegance. The working group sided with Hallam-Baker.
The jury may still be out on another XML concern, verbosity. Microsoft designed the Caller ID syntax to be terse for an XML vocabulary, with tags being one or two, occasionally three characters long. Detractors note the performance implications for DNS when it is asked to store large chunks of data. DNS usually stores relatively short amounts of data. Each item is limited to 512 bytes, although there are ways to extend them. Also, increasing the size of entries in DNS might require that it be queried using TCP rather than the faster UDP.
Dave Crocker, author of RFC 822 (the standard for text messages sent, for example, in e-mail, a standard so old it was written for “ARPANET”), is concerned about the complexity of the Sender ID proposal and sees it as an invitation to new security problems, inefficiencies and miscellaneous other errors. While he sees value in validating the From: and some other header fields, he doesnt actually see spoofing as an inherent part of the spam problem, and therefore Sender ID is not a direct response to it.
What Happens Now
?”>
As fast as the process has gone so far, and thats very fast by IETF standards, the process has a ways to go. According to Andy Newton, the working group will meet in San Diego to put finishing touches on the draft documents, and then a “last call” goes out to the working group.
“Once the working group has consensus on these documents,” according to Newton, “we will send them to the IESG (Internet Engineering Steering Group) for approval. ” The IESG will then issue an IETF-wide last call. Once IESG concerns are satisfied, the documents will be given to the RFC Editor, where they will be published as a Proposed Standard. (RFC 2026 covers the IETF standardization process.)
Its easy to notice the dissension in the working group discussions, but its not too hard to notice the support for the standard as well, at least with respect to individual parts of what is a complex standard. Levine has a point in his observation that the SMTP we have all come to know over the years is a very simple standard (after all, the “S” in SMTP is for “simple”). Sender ID makes it much more complex.
Many have expressed skepticism that the Internet community will move quickly to adopt the new standard, but they may be pushed along sooner than they would expect. According to Meng Wong, AOL and Earthlink are already publishing SPF records and Microsoft recently committed to do so. If all the major mail providers start supporting SPF or Sender-ID and classifying mail based on them, other parties may need to join in lest their mail be relegated to a disreputable status and placed in the “Unauthenticated” folder of E-mail users.
The leadership of the IETF and the working group may recognize the importance of this, as have the major mail server vendors, such as Sendmail, most of whom have also committed to work with the standards.
The alternative is, at the very least, unpleasant: Spam will continue to increase as a percentage of Internet e-mail, and the only methods to stop it, filtering software, will lose the arms race.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page:
More from Larry Seltzer
