Re: [fetchmail-users] broken POP3 servers - future fetchmail policy (IMPORTANT)

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

Rob MacGregor <rob...@gm...> writes:

> On 03/01/06, Matthias Andree <mat...@gm...> wrote:
>>
>> fetchmail's task is to fetch all messages exactly once, nothing more,
>> nothing less. If we must fetch a message twice because the transfer was
>> interrupted, well, bad luck.
>
> You sure you're not ESR in disguise :-)

100% sure I'm not ESR. 

> I'm happy with that statement, if by fetch you mean "download and hand
> it on to the specified MTA".

That's what I was trying to say: download completely, hand on
completely, obtain status of destination SMTP/LMTP/BSMTP/MDA, and only
assume "completed" if every step succeeded. If any intermediate step
fails, we'll retry the message next time. Although it's bad luck we've
missed the goal of one attempt, and we'll have 1.7 downloads or so.

> Otherwise the statement sounds like you don't care of there's a
> problem with the local MTA, fetchmail will have done it's bit by
> downloading the email, chucking it at /dev/null and deleting it from
> the remote server...

Fetchmail will continue to make as many attempts as necessary to
retrieve the message for reliable protocols such as POP3+UIDL.

This requires co-operation of the server though, like not doing stupid
things such as deleteing the message without knowing if the client was
able to store the message. Looking at code and FAQ, many TOP
implementations leave things to be desired.

Some minor polishing has yet to happen though, for instance, after a
crash, fetchmail may retrieve messages it had successfully retrieved and
delivered before the crash, causing duplicates, but better get a message
again that you have already read than miss out on one you hadn't
read. We could reduce the number of duplicates by checkpointing the
.fetchids more often.

-- 
Matthias Andree