Re: [fetchmail-users] Mails lost due to --flush option ?

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

Frederic Marchal <fre...@wo...> writes:

> I quote the man page of version 6.3.2:
>
>       -F | --flush
>              POP3/IMAP only.  Delete old (previously retrieved)
>              messages from the mailserver before retrieving new
>              messages.  This option does not work with ETRN or ODMR.
>              Warning: if your local MTA hangs and fetchmail is
>              aborted, the next time you run fetchmail, it will delete
>              mail that was never delivered to you.  What you probably
>              want is the default setting: if you don't specify `-k',
>              then fetchmail will automatically delete messages after
>              successful delivery.
>
> Is it still true that a mail is lost if the MTA hangs  ? It sounds like
> a known bug and may have been fixed in the code but not in the man page.

Well, it indeed appears the bug got fixed. Messages will get delete:

1. if --flush is _en_abled and an "old" message is encountered
   (--flush also disables fastUIDL code in POP3)

2. if --keep is _dis_abled and a message has successfully been shipped

I don't see how a local MTA hang could cause message deletion --
delivery problems inhibit deletion and marking a message as old.  EXCEPT
if the server implicitly marks a message seen (IMAP2 and POP3 without
UIDL)

> I explain my situation: if the connection with the pop3 server drops,
> all the DELE commands are forgotten (as required by the pop3 protocol if
> I understand it right)

correct.

> and the mails reappear on the next poll.

That's a problem I can confirm looking at the code. POP3 delete attempts
mark a message seen (rather than deleted), and thus the message is
skipped.

If you are using ONLY "POP3 + UIDL" configurations, --flush should be safe.



Frederic Marchal <fre...@wo...> later answered:

> I tested it on the test server and it worked as expected. Now, it is in
> production but I may have to wait until next Monday for the flood of
> mails from the week-end to know if it is ok (and hope the connection
> drops :-) ).
>
> BTW, isn't it another way of doing the flush you said was a scary thing ?

Well, it is in fact fishing in --flush's pond functionality-wise,
so I am not going to apply that patch now.

I'll post an experimental test patch to fix the original bug later, but
it's fairly intrusive, so it needs testing and review.

-- 
Matthias Andree