[Top] [All Lists]

Changing RFC 5322 guidance about crlf.crlf response delay

2010-08-11 09:22:48


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?


  Dave Crocker
  Brandenburg InternetWorking