[Top] [All Lists]

Re: what to say on timeout?

2004-01-05 18:00:22

----- Original Message ----- 
From: "Paul Smith" <paul(_at_)pscs(_dot_)co(_dot_)uk>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Monday, January 05, 2004 12:44 PM
Subject: Re: what to say on timeout?

I don't think it really matters...
If you send such a 'response' asynchronously, then either the client has
died somehow and won't see the response, so it won't matter, or it won't
listening for data and won't see the response so it won't matter, or it
will see the response which will be useful.


Actually, my reading of RFC 2821 shows an inconsistency....


If it *IS* shutting down the SMTP service, (in which case 3.9's 'MUST NOT'
is meaningless), then the rest of 3.9 says that you SHOULD send a 421
response asynchronously, whether the client is expecting it or not.

I agree   However.  the way I finally "realized" the intent 3.9 in practice
was that it helps to minimize incomplete sessions that may incur unnecessary
retries by a sender.

    -  After receiving a QUIT command and responding with a 221 reply.

In my view, implies to allow the client to fulfill its transaction (accepted
mail or not) by allow it to drive the server to completion.

   -  After detecting the need to shut down the SMTP service and
      returning a 421 response code.  This response code can be issued
      after the server receives any command or, if necessary,
      asynchronously from command receipt (on the assumption that the
      client will receive it after the next command is issued).

In my view, implies that the possibility of passive disconnects may
perpetuate a retry, hence it is might be better to send "something."

However, I agree with you that in for a client idle state, disconnecting
with or without a 421 does not matter, especially since it is more than like
that the data will not be read by the client anyway due to the socket

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