eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
SMTP authentication is coming. But in what form?
There is a broad consensus among experts that SMTP authentication, by which Internet mail servers will be able to confirm that messages sent to them come from the domains from which they purport to come, will help to fight spam.
Nobody thinks its the cure for spam, although many (myself included) think its a substantial and necessary ingredient in drastically setting back the infection of spam on the e-mail system.
Several major initiatives have been announced over the past year or so, the big three being the Sender Policy Framework (SPF, formerly “Sender Permitted From:”), Yahoo Inc.s Domain Keys and Microsoft Corp.s Caller ID for E-mail.
At a regular IETF meeting in Seoul, South Korea, in February, a formal IETF working group was created at the urging of SPF advocates. The group, called MTA Authorization Records in DNS (MARID), has a charter that is interesting and, for the most part, admirable.
The group will focus (as the group name might imply) only on MTA authorization, and only on DNS-based mechanisms. It maintains a fairly rigid and aggressive schedule for making certain key decisions.
The group is an outgrowth of the Anti-Spam Research Group (ASRG), a part of the Internet Research Task Force (IRTF). The ASRG has produced a digital mountain of discussion but not a whole lot of consensus on actual solutions, and theres way too much topical variety and digression on the groups mailing list. All of this is perhaps why some folks went to the IETF asking to be saved from themselves and to have a standard put on the “railroad” track.
The group really began talking about things just about a month ago. According to the charter, there are major decision-making milestones in May and June and a working-group document submission in August. If the process only amounted to rubber-stamping the SPF specification, the schedule would be a breeze to meet, but as I have said, there are three major proposals with big differences among them. Theres no question that someones interests arent going to be met.
A bit of technical background is necessary here: RFC2821 is the specification of the SMTP protocol, including some addresses used in what is called the “envelope” of a message for saying where the message is going.
RFC2822 is the standard for the format of the message transmitted by SMTP; this includes all of the message headers and defines what the user sees as the “From:” and other key addresses. SMTP authentication proposals generally focus on one or the other of these.
The chairmen of the working group, Andrew Newton and Marshall T. Rose, announced April 29 that the group would focus on RFC2821 identities, meaning envelope identities—basically meaning SPF.
As they say, there is a strong consensus that further checking based on RFC2822 (message header) identities should be done, but basically this will be put off so the group can meet its aggressive deadlines, unusual deadlines for the IETF.
Next Page: Chairmen say framework must support RFC2822 mechanisms.
Supporting RFC2822
The chairmen also say they believe that the framework developed needs to be capable of supporting the needs of an RFC2822 mechanism. I asked Meng Wang Wong, chief architect of SPF, whether it is extensible enough to take on such a job and got an enthusiastic yes.
“SPF was designed with things like Caller ID and [Domain Keys] in mind and is extensible to support both of them. No change to the existing specification is needed.” He is also continuing efforts to work with Microsoft and Yahoo.
The authors of this new spec will certainly know that its only the beginning, because RFC2821 identities are far from adequate. All a spammer (or worm) needs to do is to use a legitimate envelope address, and the message can come through to the user presenting fraudulent addresses. In other words, 2821-focused solutions dont do anything to address the phishing problem.
What 2821 solutions do allow is the potential for rejecting messages without having to read them first. In other words, if you can determine that the envelope violates policy, you can reject it without actually getting the spam or worm onto your system.
Some on the MARID mailing list have challenged the idea that you can do this reliably. Some of the challenges are reasonable, some not, but clearly RFC2821 is not the complete answer.
Of course, if RFC2822 identities were easy and dispositive, there would be a consensus on them, but there isnt. Microsofts Caller ID relies on these identities to address the phishing problem. Lots of people have problems with Caller ID, the specific proposal, not least with the comparative verbosity of the syntax. And there have been credible arguments that there are ways to get around RFC2822 checks.
I spoke to Rand Wacker, director of product strategy at Emeryville, Calif.-based Sendmail Inc. Sendmail is uniquely positioned for this issue, being perhaps the most significant MTA vendor. It has no particular interest in one approach or the other and has been working with developers of all of them to bring working code into the real world, where users can experiment.
Wacker said Sendmail would like to get a variety of approaches out there for real-world testing. Remember, you dont need to support only one; a single site could support multiple standards, and theres reason to. As Wacker points out, IP-based solutions such as SPF and caller ID break mail forwarding.
Even Meng Wang Wong has said on the MARID mailing list that he believes the eventual solution to RFC2822 authentication should involve cryptography, an allusion I assume to Yahoos Domain Keys. Many experts Ive spoken to admire Domain Keys and wish it were more implementable at present.
Unfortunately, it faces a number of challenges, including the fact that Yahoo has never really announced it and certainly has no final specification. Theres also a lot of concern that the cryptographic requirements will overburden old mail servers, but Sendmails Wacker said that in the companys work with Domain Keys, the CPU requirements have been reasonable.
All of this leads me to believe that the group is moving far too fast. I agree with Wacker about real-world experimentation. Is it really necessary to have a standard so quickly, when were so early in the real-world implementations of the major proposals? I wish we could wait to get more experience with them first.
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