Quoting from Matthias Andree's mail on Fri, Mar 17, 2006:
> > 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?
What should be the new default protocol be then, imap or pop3?
Yes, protocol auto should be removed as it is confusing.
> > - 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 the connection to the mailserver breaks for any reason, mails get
downloaded again in POP3. The only POP3 setup which downloads mails
exactly once and deletes the downloaded mails is:
poll mailserver
protocol pop3
uidl # required for unique download
no fetchall # required for unique download
no keep
flush # to directly delete mails downloaded before the previous socket error
Unfortunately, this setup is not documented in the FAQ anywhere. I was
hoping to cover it in the proposed FAQ section:
C#. Ok, I choose POP3. What next?
Due to the overhead of "uidl", I would prefer suggesting 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...
Ok.
> > 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.
On a slow connection, I feel that the download and delete setup works
the best. Yes, POP3+UIDL can definitely handle it, but I think that
IMAP can do it in the minimum amount of traffic. However, I think the
wording of my point is wrong. Here is how it should be:
==========================================================================
- If you are having a slow connection to the mailserver and/or expect
frequent socket errors from the mailserver, you should consider not
leaving a copy on the mailserver. This is because leaving a copy on
the mailserver adds a small but significant amount of traffic from
the mailserver in every poll.
If you still prefer leaving a copy on the mailserver, choose POP3
with the "uidl" option. If you prefer not to leave a copy on the
mailserver, choose IMAP.
==========================================================================
> >> 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 sanity checking part is indeed correct.
Pipelining will, of course, require a lot of work. Also, getting the
full UIDL list might actually turn out to be a lot faster than
pipelining if there are many new mails.
I still have reservations about fetching the whole UIDL list
immediately after detecting the mismatch. If it is postponed to the
next poll, it should be ok.
--
Sunil Shetye.
|
