[Top] [All Lists]

Re: what to say on timeout?

2004-01-07 11:09:23

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, 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.

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

In Section, 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.

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.

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