Re: [fetchmail-users] [PATCH] Re: fix lost POP3 deletes

[Matthias A. <mat...@gm...>]

Sunil Shetye <sh...@bo...> writes:

>> Opinions? Let it go in now or wait until 6.4.0?
>
> A far safer option is to just redownload the mail. I think, there are
> issues regarding POP servers recycling UIDs, thereby assigning the
> same UID of a mail which was deleted to a new mail.

> For such servers, there could also be a race condition on a socket
> error. For example, if fetchmail sends a "QUIT" which the POP3 server
> receives and if the POP3 server sends an "+OK" which fetchmail does
> not receive due to socket error. In this situation, the server has
> already expunged the mails but fetchmail does not know that. Now, if
> the server assigns the same UID to a new mail, fetchmail may end up
> deleting that mail.

Well - that problem hurts the existing UIDL code, too, independent of
--flush. When fetchmail gets an error response to QUIT, it will not
forget existing UIDLs, thus it may skip messages with recycled UIDs when
the server has in fact seen the QUIT message.

> This patch should now download the mail when used without 'flush'.
> This will lead to duplicate mails on socket errors.

Well - fetchmail does not currently save the deleted status to its
.fetchids file, so there will be a difference between daemon mode and
"fetchmail without daemon option from cron" that I would like to avoid -
and my patch is supposed to address this.

I am attaching a revised patch (against UIDL) that drops the UIDs (marks
them UID_EXPUNGED) before sending the QUIT command.

My patch saves the "DELETED" flag, and this should help when the
connection goes away, for instance, when downloading a message, when
there is not the slightest chance the server might have seen a "QUIT"
request, so there is no chance of recycled UIDs.

In that case, fetchmail would then safely retry the deletion.

The problem of another client deleting a message and the server
recycling the UID isn't fixed, we cannot fix this in fetchmail.

-- 
Matthias Andree