By Larry Seltzer  |  Posted 2004-08-02 Print this article Print

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.

Next page: What happens now?

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel