[fetchmail-users] Re: fix lost POP3 deletes

[Sunil S. <sh...@bo...>]

Quoting from Matthias Andree's mail on Wed, May 24, 2006:
> 
> Yes, it will. But how can we reliably tell "server received QUIT" from
> "server did not receive QUIT"? Do we get OS errors because the TCP
> ACK-flagged packets didn't come back, or because we got some ICMP or
> RST? Was the crucial ICMP perhaps dropped by the usual asinine firewalls
> that block all inbound ICMP? What kernel and version uses which codes to
> report issues? We might perhaps try "STAT" before resetting the flags so
> as to check if the connection was broken at the time we reach the logout
> code, but how else can we handle this?

I think, the current code which is assuming that mails have been
expunged only on a successful quit is ok. It is a straighforward code
which is not hard to understand. Setting UID_EXPUNGED before sending
QUIT is probably going to make the code harder to debug, especially in
the edge cases. Another case I can think of is:

POP3> QUIT
POP3< -ERR Disk full

What is probably required is to directly delete the mails which have
been deleted (UID_DELETED), but not yet expunged.

> >> In that case, fetchmail would then safely retry the deletion.
> >
> > Undoubtedly, saving the flag is required. However, to keep things
> > simpler, it would have been better if this issue was fixed separately.
> 
> Can you elaborate how to handle this separately?

I mean, your patch is doing three things:

- Adding comments to the code, fixing other minor issues
- Adding the UID_PENDDELE flag
- Saving and restoring the DELETED flag in .fetchids

The above issues are equally important. But they are separate issues
and should be addressed separately. I am saying this only to keep the
size of the patch under discussion small.

> BTW, we need the "DELETED" flagging in .fetchids to make your
> "UID_UNSEEN" patch (re-fetch rather than mark seen) anyways. 
> Else everything becomes "SEEN vs. UNSEEN" next time fetchmail is
> (re-)started anyways.

Handling it in .fetchids requires more thought. Just adding the
DELETED word is not enough. Atleast, an expiration time will have to
be added to the DELETED flag. What if a person runs fetchmail after a
week or more? In this case, it is probably unsafe to assume that it is
the same old mail which should be deleted directly.

Another potential problem: what if the user is running the second
instance of fetchmail with 'keep'? I think, your patch will still
delete the mail directly (not checked).

-- 
Sunil Shetye.