[Top] [All Lists]

Re: what to say on timeout?

2004-01-07 08:10:47


Folks, I'm happy to rework the text if there is consensus that change is actually needed, and, ideally, if someone supplies the suggested text. However, after rereading the text, and the predecessor text in RFC 821, it actually seems clear to me what is intended...

Please remember, in reading this, that 821 tried to define things independent of the particular properties of TCP and that 2821, unless circumstances required something else, tried to preserve that model.

Given the synchronous model of SMTP, which several people have discussed on the list, the "timeout" limits are intended to let the server detect a client that has died or gone silent without closing the TCP connection. SMTP's concern is that

        (i) this not be done too quickly, causing unnecessary
        mail delays, retries, and confusion (see the
        introduction to and
        (ii) clients that have, in fact, died or disappeared do
        not tie up server or network resources indefinitely.

Now, all of the timeouts specified occur when the server is waiting for a command or data from the client.

If a timeout expires, the assumption is that the mail session is over, that the client has died, and that the server should take an appropriate action. Now let's look at 3.9...

The two bulleted statements are inapplicable, not because they don't list this case, but because the SMTP server isn't "intentionally closing the connection". Instead, it has detected a state it interprets as the client having dropped the logical connection (even if the TCP connection is still up). The next two paragraphs strengthen this impression -- they talk about receipt of unknown commands and "shutdown via external means", which is fairly clearly not the client timing out.

So, the timeout expires and the server concludes that the client is gone, even though the TCP connection isn't. What does the standard permit the server to do then? The answer --as is the answer several other places in the SMTP specs-- is "anything sensible". "Sensible" may differ in different situations:

(1) Is it sensible to simply shut down the network-level connection?

        Yes.  By having the timeout expire, the server assumes
        that the applications-level connection is gone.

(2) Is it sensible to send an asychronous 421 (or, under unusual circumstances when one hopes to not hear about that message again, a 5yz code) to the client, hoping that will wake up up, wait a short interval to see if there is a response, and then close the connection?

        Yes, although, as others have commented on the list, it
        is unlikely to accomplish very much in most situations.
        On the other hand, it is, at worst, harmless.

(3) Is it sensible to send some sort of TCP signal, e.g., a SYN, to see if the client can be woken up.

        Yes, although, for lots of reasons, this shouldn't be
        "required" or even "strongly recommended" behavior, it
        certainly shouldn't be prohibited either.

So, one way to interpret what the standard says today is

        * There is _no_ specific and prescribed behavior because
        there isn't intended to be any specific and prescribed
        * Servers are, as in all other things, supposed to
        exercise good sense in the environment in which they
        find themselves.

Does that help?
Do we really need more text and, if so, what?


--On Tuesday, 06 January, 2004 00:07 +0000 Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:

At 19:40 05/01/2004, you wrote:

Hector Santos wrote:
Send a 421 per RFC 2821 section 3.9.

I think RFC 2821 needs clarification here.

Nowhere does it say what an SMTP server should do after a
timeout. Section 3.9 says that the SMTP server MUST NOT close
the connection except in two situations - which do not include
a timeout situation...

So, although section allows (recommends) the SMTP
server to have a timeout, it isn't allowed to close the
connection after the timeout - so what should it do??

I'm pretty sure this isn't what was intended by RFC 2821, but
it's what it says..

So, I'd suggest that 3.9 have an extra possible cause of a
connection termination as a 'timeout situation as described in'. At this point in the RFC it could be suggested what
the server should do.

(The logical thing is probably to treat a timeout situation
the same as a 'SMTP server shutdown situation' - ie it SHOULD
attempt to send a line containing a 421 response code

Paul                            VPOP3 - Internet Email Server/Gateway

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