On Aug 11, 2010, at 6:52 AM, Dave CROCKER 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?
Ignore the non-conformists. As with many other bits of 5321, ignoring the
timeouts can make delivery of mail more economical in resources at the expense
of reliability. That's a reasonable operational decision to make, in some
cases, but not something to encourage. Adding an explanatory note as to why
that timeout is so long might help implementors make better decisions, though.
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. "
"A receiver-SMTP SHOULD reject a message it does not intend to deliver
during the SMTP transaction rather than sending an error message to
the reverse-path after accepting the message if it can determine that
before responding to the <CRLF>.<CRLF> end of data indicator.
However, to avoid receiving duplicate messages a receiver-SMTP
SHOULD minimize the time required to respond the <CRLF>.<CRLF>
end of data indicator and MUST respond within X minutes."
(Where X of about 2 seems reasonable).
The first paragraph has broader implications, but I think they're
a good thing to consider.
Cheers,
Steve
Does anyone suggest considering modification to any other text in the
document?
Does anyone have useful text to suggest for adding or changing?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net