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.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 email@example.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 firstname.lastname@example.org sends a message to email@example.com. Mail sent to firstname.lastname@example.org is forwarded to email@example.com. The recipient-domain.com mail server sees the message come in with MAIL FROM: firstname.lastname@example.org, but in fact it is sent from email@example.com. By adding the submitter extension to the SMTP command (MAIL FROM:firstname.lastname@example.org SUBMITTERemail@example.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. Next page: What happens now?
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.