On 1/7/2004 9:10 AM, John C Klensin wrote:
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.
The client could simply be waiting on some other event or input, like a
password for AUTH, and not borked or dead.
Separately, timeouts are server-based, and variable for each server, but
there is no mechanism for servers to inform clients of the timeouts in
use. It's entirely possible that a particulr server will timeout faster
than the client expects, although this is discouraged.
(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.
Do we really need more text and, if so, what?
The robustness principle requires us to assume that the client is not
borked but instead is merely waiting. The most conservative thing to do is
to tell the client why the session is being dropped unilaterally.
The end-to-end principle requires the application-layer to communicate
this kind of stuff, rather than relying on other layers.
SMTP requires explicit signalling in order for the queuing and routing
algorithims to work reliably. A 421 will force a requeue, and that is the
approriate recovery.
So, it seems to me that 421 is always appropriate and correct, regardless
of whether or not any other mechansisms (like TCP probes) are also tried.
As long as the socket isn't blocked, the server should send it.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/