Re: what to say on timeout?

I would argue that a new reply code be assigned to SMTP server timeout.

I would argue against using 421 because that means something 
distinctly different.  A well programmed SMTP client which notices 
that it has received a 421 may conclude "Service not available" 
(reference Sections 4.2.2, 4.2.3), may therefore add the host to "a 
list of hosts it cannot reach" (reference Section 4.5.4.1), and may 
erroneously postpone further attempts to reach that host.
Also, although John is probably correct in assuming that the client 
has already dropped the connection when the server reaches timeout, in 
the large majority of cases, I guess there will inevitably be a few 
cases when the client does come back and read what the server has last 
written.  In these few cases a distinct code for timeout could clarify 
what happened.
In one more case I can imagine good coming from a distinct timeout 
code.  What if the timeout is malfunctioning? happening too quickly? 
The administrator at the client end could find information in his logs 
which might help the administrator at the server end debug the problem.
However, I accept there must be very good reasons for not expanding 
the list of reply codes.  Further, as experience produces more 
encounters with antagonistic SMTP clients, it may be best to keep your 
cards close to your chest; in a hostile environment it can be a 
mistake to give more information.  So I cannot judge entirely whether 
the benefits of adopting a distinct reply code for timeout would 
outweigh the costs.



Nonetheless I will respond to John's request for a suggestion for what 
the new text might say.
FIRST
Add a third "not...except" point to Section 3.9:

- After waiting too long for the next command from the client or after 
detecting too slow a rate of data transmission.  In this case the 
server may either close the connection silently or send a 422 response 
code before closing the connection.  See section 4.5.3.2.
SECOND
In Section 4.5.3.2, after the last sentence (which says "An SMTP 
server SHOULD have a timeout of at least 5 minutes while it is 
awaiting the next command from the sender.") add:
It may [or SHOULD?] also monitor the rate transmission while it is 
receiving the message data and may [or SHOULD?] time out if this rate 
is too slow.
THIRD
the new code would need to be added into the lists in both Sections 
4.2.2 and 4.2.3, such as:
422 Timeout: either too much delay between commands or too slow a rate 
of data transmission.

I cannot defend the particular number, 422, as being better than other 
4xx, or even possibly 5xx, reply codes for this timeout situation.  I 
picked 422 mostly because it is so close to 421, with which it shares 
the aspect of asynchronous termination by the server.

My suggestions above are tentative, of course.  RFC 2821 is already a 
large and complex document, in which a given subject (such as the 
current subject of timeouts) may be addressed in several sections, and 
great care (which I have not exercised in the above, tentative, 
suggestions) must be needed to change one section without breaking the 
intent of another section.  You have my sympathy, John.
Rich Hammer
Hillsborough, N.C.
mailscreen.net