[Top] [All Lists]

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

2010-08-11 10:19:06

On Aug 11, 2010, at 6:52 AM, Dave CROCKER wrote:


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 

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.


Does anyone suggest considering modification to any other text in the 

Does anyone have useful text to suggest for adding or changing?


 Dave Crocker
 Brandenburg InternetWorking