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