Re: [Asrg] 6. Proposals - AMTP (rev 01)

[Yakov Shafranovich <[e-mail]>]

Bill Weinman wrote:
> At 11:13 PM 9/28/2003, Yakov Shafranovich wrote:
> 
>> Second, I would like to ask if you can clarify for us whether your 
>> proposal seeks to replace SMTP completely. 
> 
> Yes, AMTP is intended as a replacement of SMTP. It is also substantially 
> derivative of SMTP, a design decision intended to ease transition.


First of all Bill, please keep in mind that we are not out to get you 
here, rather we have seen the idea of replacing SMTP being discussed 
many times before (check the archives) and there are many reasons 
against it. We would consider this step, IF determined to be necessary, 
as a long term solution skin to deployment of DNS-SEC or IPv6.

Second, are you aware of other efforts underway to provide a protocol to 
replace SMTP. Especially the following:

AMDP - http://www.ietf.org/internet-drafts/draft-fakih-amdp-00.txt
AMTP - http://www.danisch.de/tmp/draft_mtp.txt
AMTP - http://www.ietf.org/internet-drafts/draft-crouzet-amtp-00.txt
Pull proposals such as IM2000, etc.

There are also many additional proposals mentioned in the list archive 
(use gmane.org to search).

> 
>> "    The idea of replacing SMTP is appealing because it
>>      permits thinking in terms of creating an infrastructure
>>      that has accountability and restrictions built in.
>>      Unfortunately an installed base the size of the
>>      Internet is not likely to make such a change anytime
>>      soon.  It seems far more likely that successful spam
>>      control mechanisms will be introduced as increments to
>>      the existing Internet mail service."
> 
> 
> I am acutely aware of this issue and AMTP addresses it by maintaining 
> the overall design and command set of SMTP. AMTP is substantially 
> derivative of SMTP and as such the transition should be, not entirely 
> trivial, but as close as possible without sacrificing its operational 
> advantages.
> 

I want you to reconsider this issue again. Keep in mind who wrote the 
technical considerations document where this has been taken from - Dave 
Crocker. He is the same person who wrote RFC 822 and has a tremendous 
experience with email. He had also written additional comments 
(http://news.com.com/2009-1081_3-5060650.html) on the idea, specifically:

"
o E-mail authentication mechanisms already exist. They are not used very 
much. Why would a new mechanism fare better?
o When there is real consensus about the functional changes that are 
needed for e-mail, we can start deciding what technical changes will 
achieve them. Only when we find that we cannot modify SMTP to provide 
them will it make sense to consider replacing SMTP.
o Authenticating an e-mail sender will not prevent spam. It might reduce 
some kinds of it, but a great deal of spam is from people who are 
perfectly happy to be correctly identified.
"

He has stated also that:

"In general, solving spam will be easy--as long as we ignore the 
installed base of users; the human side of living with the changes; the 
need to scale use by everyone, everywhere; and the possibility that 
spammers can easily work around any particular prevention mechanism."

It would be very useful to the group in general if we had an analysis of 
whether SMTP needs to be replaced in line with Dave's suggestion above. 
Replacing SMTP is an architechtural issue for the entire Internet. The 
Internet Architechture Board (IAB) which is above both the IRTF and the 
IETF is aware of the issue and will be evaluating it, so this evaluation 
will have input from them.

>> In particular we would like to consider whether it would be more 
>> viable to reformulate your protocol as an ESMTP extension rather than 
>> a replacement for SMTP.
> 
> 
> I considered that approach carefully. Ultimately I realized that the 
> SMTP protocol REQUIRES (in the sense of RFC2119) a level of promiscuity 
> that would prevent AMTP from accomplishing its goals.
> 
> I spent many hours on transitional planning before I wrote the first 
> draft, and I am working on documents to describe the transition process. 
> In short, once I have working code I will provide tools to make the 
> adoption of AMTP sufficiently painless that I expect it to be adopted, 
> gradually, by a sufficient number of hosts to constitute a critical 
> mass. Time will tell of course, but I have yet to see any argument that 
> convinces me otherwise.
> 

I am assuming that you are planning on submitting this protocol as a 
standard to the IETF or as an RFC. In that case, I would suggest that 
you address the deployment and adoption issues in great detail. 
Additionally, the IAB will be considering the issue at some point and it 
is important to watch what they will come up with.

> ---
> Never send a monster to do the work of an evil scientist.

BTW, I love the quote :)


_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg