Re: what to say on timeout?

> 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).
Actually, I'd read a 'timeout connection close' as 'intentionally closing 
the connection'. If the server 'does nothing', then the connection could 
well stay open indefinitely. So the server has to close the connection. 
Hopefully, it'll do this deliberately, not by accident. So, in my reading 
it's an intentional close. (This isn't trying to be pedantic, just clear - 
if it's not clear, then there'll just need to be another SMTP standard 
after 2821 to clarify it..)
I don't think you can say that a timeout will only occur when the client 
has 'dropped the logical connection' (whatever that means). It's entirely 
possible the client is busy doing something else and is just taking a long 
time to do so (this is, presumably, why the timeout is limited to a minimum 
of 5 minutes, when, in reality, an SMTP client which is inactive for more 
than 30 seconds is probably 'dead' in most cases). So in this case it is 
definitely that the server is intentionally dropping the connection when 
the client is still happily connected.
So, I'd add 'timeout' to the list of possible causes of an intentional 
close of the connection.
> 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.
Hmm, I took that as meaning that the server shouldn't shut down the 
connection in any other situation (which clearly isn't what it was meant to 
mean, but seemed to me to be what it said).
> 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".
But that isn't what RFC2821 says.. It might be what it's meant to mean, but 
it doesn't say it.
> 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?
Not really, as you say, that's "one way to interpret what the standard 
says"... What a standard should try to aim for is "the only way to 
interpret it", not "hopefully you'll interpret it the way I meant you to"
> Do we really need more text and, if so, what?
I'd say yes. If you want it to mean what you give as a possible way to 
interpret it - put that into the standard. I'd say if there's a point of 
uncertainty which isn't just one person being dense then it needs to be 
clarified. This one has a few people giving different responses, so, IMHO, 
it needs clarifying.
Personally, I'd say the 421 SHOULD be sent on any 'intentional closure' of 
the connection other than following a QUIT command. (This isn't actually 
what our own mail server does at the moment, so this isn't a vested interest)

Paul                            VPOP3 - Internet Email Server/Gateway
support(_at_)pscs(_dot_)co(_dot_)uk                     http://www.pscs.co.uk/