ietf-mxcomp
[Top] [All Lists]

There can be more than one

2004-08-19 07:31:49
Folks,

Admittedly, I am new to this IETF process but it appears to be substantially different than other standards processes with which I have been involved (W3C, UPnP and, cursorily, OASIS). In the IETF, because it is a "running code" organization, there appears to be a standard practice that multiple protocol additions can be in process at the same time. Furthermore, multiple mechanisms are frequently deployed on the network. For example, while Sender-ID is going out the door "first", it is to be quickly followed by MPR (nee CSV-BATV?). Both of these have been preceded in implementation by SPF Classic. We are now entering the implementation phase of these standards.

In the race for anti-MTA forgery technology (RFC2821 time IP Authorization), SPF Classic is clearly ahead. Sender-ID barely addresses anti-MTA forgery at all. In the race for trying to solve the anti-phishing problem, Sender-ID provides one extra step that will need to be buttressed by whatever IETF MASS WG produces. In other words, in classic IETF fashion, the pieces will sort themselves out, based on efficacy/utility, on the network.

With respect to the above, I would suggest that SPF Classic be resubmitted to MARID as an anti-MTA forgery technology. The SPF/Microsoft deal to eventually support MAIL FROM checking (as judged by Mr. Lyons recent comments on this list) does not appear to exist. We need both RFC 2821 and RFC 2822 time checking. We will be considering MPR (which attempts to do both) in the near future. The engineering process for effective anti-spam technology is just beginning.

Andrew

P.S. For those on this list who fear Microsoft's market power, you should just relax. Yes, Microsoft has a huge amount of market leverage. Yes, they will be able to modify both Outlook and Outlook Express to advertise the PRA. Yet, they also suffer from real economic forces. Changes to MUAs cost them and their customer's money, time and labor. Therefore, changes are not done lightly. If Sender-ID does not really solve the problem (which is quite intractable and, therefore, unlikely to be solved by any one approach), then IETF will layer multiple solutions to narrow the areas where spamming can occur. This will be a net improvement. Anything that reduces noise in the mail system will improve dynamic filtering. The incidence of false positives will go down because the differences between real mail and spam will be clearer to automatic analysis systems.

P.P.S. For those of you concerned about the costs of accreditation/reputation systems, you should just relax. If, as a small volume email source, you advertise your MX, reverse DNS, SPF Classic, MPR and Sender-ID records, then you have an extremely good chance of getting through anti-spam filters - you will not incur dynamic scoring penalties that would push your email into the spam category.

P.P.P.S. For those of you concerned about even one false positive, you should just relax. There is no pure technical fix that allows the unsolicited nature of email to continue. We just need to make sure that bouncing and non-delivery messages work properly so that the sender really does know if his/her mail got through. If they get the bounce/DSN, then users can use other means of communication, like the telephone or fax, to open up the channel. (For those CEOs who are expecting important correspondence from forwarders, this will sort itself out. People who do business via forwarded domains will chose forwarding vendors that help them get their email through anti-spam filters. Frankly, I do not know any CEOs that would trust the unencrypted email system today to reliably transmit business critical information, such as a digitally signed contract. These messages, if they go over email, will be encrypted with keys to well known business partners. The spam filters, because well known business partners are whitelisted, will leave these messages alone.)

____________________________________
Andrew W. Donoho
awd(_at_)DDG(_dot_)com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)

<Prev in Thread] Current Thread [Next in Thread>