ietf-smtp
[Top] [All Lists]

Re: Changing RFC 5322 guidance about crlf.crlf response delay

2010-08-11 10:30:59

(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
<dhc(_at_)dcrocker(_dot_)net> 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/



<Prev in Thread] Current Thread [Next in Thread>