[Top] [All Lists]

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

2010-08-11 10:07:56

Dave CROCKER wrote:

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?

I think its fine, but the only thing I can see is adding insights requiring real timeout values seen in practice. Its not 10 mins.

   "Practice has shown the recommended 10 minute timeout is not
    common place and closer to 3-5 minutes.  While receivers should
    DATA processing needs make this process as fast as possible, it
    SHOULD limit accumulated DATA processing time to less than
    5 minutes."

My concern is that there would be codification to DISCOURAGE data level processing and that quite frankly is unrealistic. So we embrace it and provide insight for implementator.

Of course, a constant concern would be backward compatibility to address legacy Operations. We are all for that.

However, any change proposal only applies to active systems that are in position to adapt. So any new adjusted "guidelines" should be proactive with new ideas to better address both new and old operations.

I can only see adding notes regarding how unrealistic a 10 minute timeout is in practice for LEGACY systems.

New systems will mostly like adapt and adjust and add a 10 min timeout as currently recommended by 5321.


Hector Santos