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 >
