Re: what to say on timeout?

Sigh.

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 4.5.3.2) 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
        behavior.
        
        * 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?

   john




--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 4.5.3.2 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
> 4.5.3.2'. 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
> asynchronously)
>
>
> Paul                            VPOP3 - Internet Email Server/Gateway
> support(_at_)pscs(_dot_)co(_dot_)uk                     http://www.pscs.co.uk/