--On Wednesday, August 11, 2010 09:53 -0700 "Murray S.
Kucherawy" <[email protected]> wrote:
>
>> -----Original Message-----
>> From: [email protected] [mailto:owner-ietf-
>> [email protected]] On Behalf Of John C Klensin
>> Sent: Wednesday, August 11, 2010 8:15 AM
>> To: [email protected]; 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
