[Top] [All Lists]

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

2010-08-15 20:22:12

David MacQuigg wrote:

I like the original clear and concise wording best (last paragraph of section 6.1). All three say essentially the same thing about what the receiver MUST do.

But not strong enough about what is expected of the client as well. It could easier add a statement matching the above:

     A sender-SMTP MUST carefully balance these two
     considerations, i.e., using the recommended
     10 minute timeout, or using a non-standard shorter
     timeout against receiver-SMTP who might have a delay
     after the final <CRLF>.<CRLF> and getting the reply

I mean, it takes two to tango. When clients follow the "rules," it wouldn't become much of an issue. :) Servers will always do its best to make sure the time is minimal.

Keep in mind sometimes its just a matter of using OOPS software, with virtual functions and they used a flat 5 minute timeout for each state. I've seen this in various software. I've seen it again recently in a CodeProject.Com SMTP Client C/C++ submission, nice OOPs code, but a used a file timeout and single source location for catching error timeout exceptions using a single 5 minute values. I pointed out the SMTP compliancy error to the code submitter.

Generally, server software is more robust. SMTP client software is a dime a dozen and many just need reminders there are certain guidelines to follow.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>