SMTP Authentication Hits Standards Track - ' Supporting RFC2822 ' (
Page 2 of 2 )
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.
Check out eWEEK.coms Security Center at http://security.eweek.com for security news, views and analysis.
Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page: 
More from Larry Seltzer
