--On Wednesday, August 11, 2010 09:53 -0700 "Murray S.
Kucherawy" <msk(_at_)cloudmark(_dot_)com> wrote:
-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of John C Klensin
Sent: Wednesday, August 11, 2010 8:15 AM
To: dcrocker(_at_)bbiw(_dot_)net; SMTP Interest Group
Subject: Re: Changing RFC 5322 guidance about crlf.crlf
response delay
I note, again fwiw, that I've been trying to get various
advocates for a ban (or near-ban) on NDNs to write that
separate document and propose a specific model at regular
intervals since well before 2821 was completed.
I'm new to that particular topic. Can you explain its
motivation or point me to a discussion thread that lays it out
so I can get some context?
Briefly, there was an argument in DRUMS when 2821 was being
developed, and a much longer and more intense argument when what
became 5321 was under discussion, that the nature of the
blowback problem was such that non-delivery notification
messages should be entirely banned unless the relevant SMTP
server was in a position to strongly authenticate the reverse
path.
The people who felt most strongly about that believed that, if
the only alternative to generating an NDN was to simply drop the
message, the latter was preferable. Of course, that would
change the Internet email model from one in which a sender could
assume delivery if there was no indication of a problem to one
in which delivery was uncertain and best-efforts, implying a
possible requirement for more delivery notifications.
DRUMS felt constrained to stay within existing practice and 5321
was constrained by both existing practice and the Proposed ->
Draft rules. Whatever the merits of the various flavors of
"reject only, never bounce" argument, they represented a change.
There was also some question as to whether some variations were
realistic in a relay environment (a rejection to a relay could
force that relay to generate an NDN unless one just dropped the
message).
So the people taking "reject only" positions were strongly
encouraged to generate I-Ds describing their models, see if they
could get consensus for them, and then see if they could get
sufficient implementations and interoperability testing to
"catch up" with 2821bis or 5321bis and be incorporated there.
For whatever reason, the drafts never appeared so we don't know
what might have happened if they had.
"Long delays after the <CRLF>.<CRLF> is received can
result in timeouts and duplicate messages. Deferring
detailed message analysis until after the SMTP
connection has closed can result in non-delivery
notifications, possibly sent to incorrect addresses. A
receiver-SMTP MUST carefully balance these two
considerations, i.e., the time required to respond to
the final <CRLF>.<CRLF> end of data indicator and the
desirable goal of rejecting undeliverable or
unacceptable messages at SMTP time."
I like this text. I think it reflects current operational
realities quite nicely.
Thanks. Certainly we have known since 1123 that there was an
operational design tradeoff in this area. The original 1123/
2821/ 5321 text just about said that. If we can explain the
tradeoff a little better, even while avoiding making a specific
recommendation about the decision (or going all the way to
"never bounce"), that probably helps.
john