[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 akin 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 architectural issue for the entire Internet. The 
Internet Architecture 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
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg