Subject: There can be more than one

From: "Andrew W. Donoho" <[email-masked]>
Date: Thu, 19 Aug 2004 09:29:35 -0500

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
[email-masked], PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)

---

From: Andrew Newton <[email-masked]>
Date: Thu, 19 Aug 2004 11:05:51 -0400

On Aug 19, 2004, at 10:29 AM, Andrew W. Donoho wrote:
> For example, while Sender-ID is going out the door "first", it is to 
> be quickly followed by MPR (nee CSV-BATV?).

MPR is not a working group item.

Some of you may have noticed that this is a high-volume list.  I was 
asked by Wayne if it was ok to start discussing alternative drafts on 
this list.  My answer to him was: go ahead and submit them as 
individuals but please hold off discussion until we have evaluated 
Sender ID.  I am not just asking this of Wayne but of all participants.

> 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.

MASS is not yet a working group.

-andy