Re: [fetchmail-devel] Re: Incorrect header line and lost mails

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

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

> Apart from the issue of fixing, what is missing is documentation on
> this. There is no place where it is written what configuration should
> a user use to derive the best mileage from fetchmail. Maybe, some FAQ
> entry like:

Looks good.

> =========================================================================
> C#. What protocol should I choose with my mailserver? My mailserver
> supports both IMAP and POP3.
>
> fetchmail, by default, uses first IMAP and then POP3 (protocol auto).

Should we deprecate this "protocol" in fetchmail proper so we can
remove it in 6.4.0?  I have a strong itch to do just that.

Somebody got any objections?

fetchmailconf could still probe for protocols (but needs to be told
about SSL) -- and actually, someone should overhaul it (and rework the
ergonomic properties. The current layout of the Tk interface is pretty
unergonomic and in some places astonishing for the user.)

> This doesn't work when you are keeping mails on the mailserver or when
> there are errors (like socket errors or deliver errors) after a few
> mails have been downloaded.
>
> So, as a first step, you should necessarily choose between IMAP and
> POP3.
>
> - If your mailserver is delivering to multiple folders, choose IMAP.
>   
> - If you want to download all mails and not leave a copy on the
> server, choose IMAP.

In --all --nokeep setups, POP3 is usually simpler - any particular
reason why you suggest IMAP here?

> - If you intend to keep mails on the server, check if your server
>   supports UIDL. If it does, choose POP3 and enable the "uidl" option.
>   With POP3 and UIDL, it is even possible to access the mailbox
>   through multiple e-mail clients without affecting fetchmail.
>
> - If you intend to keep mails on the server, but your server does not
>   support UIDL, choose IMAP. However, you should not access the

Make that "MUST NOT" access...

>   mailbox through other e-mail clients as fetchmail will not be
>   able to download all new mails.
>
> - If you are having a slow connection to the mailserver and/or expect
>   frequent socket errors from the mailserver, choose IMAP and do not
>   leave a copy on the mailserver.

This, too, is something POP3+UIDL should handle.

>> My basic idea is: say we have u UIDLs stored, and the server has m
>> messages. Then, send "UIDL" u+1 "UIDL" u+2 ... "UIDL" m pipelined
>> (non-blocking) (or, on future RANGE capable POP3 servers, "UIDL" u+1 "-"
>> m), and if ANY seen message is in that range, do slow UIDL. No binary
>> search with many round trips. Of course, this needs to track deletions
>> properly and if another client client deletes messages, needs to back
>> down and fetch the whole list. Perhaps sanity checking the last known
>> UIDL helps detecting third-party deletions on the assumption that the
>> likelyhood of the server recycling a UID is low.
>
> This might not work with "no keep" when fetchmail is not sure if the
> mails marked by fetchmail for deletion have actually been expunged or
> not.

But fetchmail knows if it has seen "+OK" or rather EPIPE in response to
a QUIT command, and in no other case than having successfully sent
"QUIT" can it assume the messages have been expunged.

-- 
Matthias Andree