Re: [tpop3d-discuss]tpop3d doesn't delete mails [ms outlook 2002]

[Jarek Woloszyn]

On śro, 04 lut 2004, Kevin Bonner wrote:

> > > See section 6 (The UPDATE State) of RFC 1939.  The server will remove
> > > messages marked as deleted _after_ it receives the QUIT command.  If the
> > > server receives the QUIT command, and the connection is closed before the
> > > client receives the response, the messages should still be removed.
> >
> > So that is a bug in tpop.
> 
> It's a bug in the client, not tpop3d.  RFC 1939 states that the QUIT command 
> will have a response.  If a client doesn't wait to receive that response, 
> it's broken and should be fixed.  If fixing a client isn't an option, hacking 
> on your local copy is a solution.

I've just read the whole RFC 1939 and there is nothing about waiting for
the response. 

> When the client issues the QUIT command from the TRANSACTION state,
> the POP3 session enters the UPDATE state.
>   If a session terminates for some reason other than a client-issued
>   QUIT command, the POP3 session does NOT enter the UPDATE state and
>   MUST not remove any messages from the maildrop.
>      QUIT
>
>         Arguments: none
>
>         Restrictions: none
>
>         Discussion:
>             The POP3 server removes all messages marked as deleted
>             from the maildrop and replies as to the status of this
>             operation.  If there is an error, such as a resource
>             shortage, encountered while removing messages, the
>             maildrop may result in having some or none of the messages
>             marked as deleted be removed.  In no case may the server
>             remove any messages not marked as deleted.
>
>             Whether the removal was successful or not, the server
>             then releases any exclusive-access lock on the maildrop
>             and closes the TCP connection.

tpop says, that there was no QUIT command, because it doen't read all the data 
from the socket. When the socket changes its state to closed, tpop ignore 
the rest of data, which can still be in the input buffer.

Interpretations may be different. 

I would be glad if there is a switch which turns tpop to the other behaviour,
or at least a good patch for that.


-- 
Jarek Woloszyn