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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg