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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net