[Top] [All Lists]

Re: what to say on timeout?

2004-01-07 09:50:07

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

        * 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

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