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

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

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

> While debugging the code, I have found a minor problem which causes
> some of the flags not being set properly on the old uid list. Here it
> is:
>
> ================================================================================
> Index: fetchmail-6.3/pop3.c
> ===================================================================
> --- fetchmail-6.3/pop3.c	(revision 4851)
> +++ fetchmail-6.3/pop3.c	(working copy)
> @@ -1019,8 +1019,9 @@
>  			     * the same mail will not be downloaded again.
>  			     */
>  			    old = save_str(&ctl->oldsaved, id, UID_UNSEEN);
> -			    old->val.status.num = unum;
>  			}
> +			/* save the number */
> +			old->val.status.num = unum;
>  		    } else
>  			return PS_ERROR;
>  		} /* multi-line loop for UIDL reply */
> ================================================================================
>
> The above patch is not actually related to any of our patches!

Merged, thanks.

> Quoting from Matthias Andree's mail on Sun, May 21, 2006:
>> 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.
>
> I think this assumes that the server necessarily receives the QUIT.
> What if the server does not receive the QUIT at all due to socket
> error? This will cause the mails to be downloaded again.

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?

>> 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?

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.

-- 
Matthias Andree