(sorry -- wrong sender address used again)
Dave,
You do mean 5321, don't you?
Of course, if the IESG hadn't put YAM into constipation, we
could modify the pre-eval document and not have to have a
discussion about errata. :-(
FWIW,
(1) My recommendation would be to retain the timeout, but note
that server implementations should be aware that some clients
will ignore the spec for operational reasons and apply a much
smaller number. My guess is that a discussion of the
appropriateness of doing that doesn't belong in an erratum/
corrigendum to 5321 but in a separate document (if at all).
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.
(2) How would people feel about moving toward changing the
"substantive text" to read something like:
"To avoid receiving duplicate messages as the result of
timeouts, a receiver-SMTP MUST carefully balance the
time required to respond to the final <CRLF>.<CRLF> end
of data indicator against the desirable goal of
rejecting undeliverable or unacceptable messages at SMTP
time rather than generating NDN messages later. "
I'll have to check whether "NDN messages" is the right reference
at that point, but it seems to me from the discussion that the
above should be about the right intent. We could go even a
little further and recast the paragraph as something like:
"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."
best,
john (as your friendly consensus-driven editor)
--On Wednesday, August 11, 2010 06:52 -0700 Dave CROCKER
<[email protected]> wrote:
>
> Folks,
>
> Responses to my question make it pretty clear (to me, at
> least) that the current text in 5322 has become off the mark,
> regarding best current practices for crlf.crlf response delay.
>
> At the time the guidance was developed, the philosophy was to
> reduce delay to the minimum and, therefore, defer any post
> crlf.crlf processing until after the SMTP session. I'm
> hearing a reasonably strong consensus that it is now
> acceptable -- and possibly essential -- to do some serious
> processing before responding.
>
> We should consider creating a Errata to cover this, but it is
> not yet obvious to me exactly what the text should be.
>
> I assume that no one is suggesting changing the 10-minute
> timeout. However, we've heard that some Senders don't honor
> it. We should consider whether to ignore these
> non-conformists versus change the time out. If the latter,
> what is a more appropriate timeout?
>
> Whatever the timeout, the consensus appears to be that it is
> OK to have "some" delay in responding.
>
> Since there will still be a timeout defining an upper limit
> and there will still be highly variable network delays meaning
> that the processing can't be allowed to come close to the
> timeout, it cannot be acceptable to give guidance that
> essentially says "take as long as you like before responding
> to the crlf.crlf." So, what guidance should be given?
>
> The substantive issue is the text:
>
>> "To avoid receiving duplicate messages as the result of
>> timeouts, a receiver-SMTP MUST seek to minimize the time
>> required to respond to the final <CRLF>.<CRLF> end of data
>> indicator. "
>
> Does anyone suggest considering modification to any other text
> in the document?
>
> Does anyone have useful text to suggest for adding or changing?
>
> d/
