Hi,
reading through the fetchmail manual page, I find a strong tendency to
drive users into using IMAP in order to overcome POP3 protocols.
Before I go into implementation details, I've used fetchmail-6.2.1 for
months with forced UIDL for all my POP3/APOP servers without unavoidable
side effects. I haven't seen any of the specters that the manual has
drawn.
I am however concerned about the current IMAP implementation and POP3
default settings, which seem to be based on something that is - I think
- a fundamental misunderstanding of how fetchmail is used, or at least
is used today.
fetchmail for the most part assumes that it were the only client ever
accessing the mailbox, but this isn't true. I check mail from various
sites at various sites and still want all the mail downloaded and still
kept on the server, so anything that assumes "\Seen -> don't retrieve"
is bugged.
1. POP3 should really use UIDL. There are various derisive UIDL
statements in the FAQ, that people who dropped LAST should be hung by
their toes or something. I vehemently object to that. Anything short
of using UIDL is a *guarantee* for lost mail as soon as another
client touches the mailbox. LAST should be dropped.
Note: A Message-ID by itself is not a sufficient substitute for a
TOP-based UIDL emulation, it is bound to miss Cc:'d mail. Calculating
a hash (MD5/SHA1) across all Received: and Message-ID: headers in a
mail might do, does anyone object?
2. I cannot use IMAP in fetchmail, because it just uses the \Seen
flag. That cannot work as I don't use fetchmail alone, but also other
clients, such as mutt and Mozilla. I'd vote for UID. Yes, that causes
--all in case UIDVALIDITY changes, which in turn causes pain servers
that bump UIDVALIDITY with every LOGIN or SELECT, but such is
life. As a (non-default) alternative for such servers, using a
user-defined flag \Fetchmail might be an alternative.
To optimize UIDVALIDITY changes, the UIDL considerations from POP3
would apply, to avoid duplicate download: hash received/message-id
headers. FETCH (BODY[HEADER.FIELDS (RECEIVED MESSAGE-ID)]) comes to
mind.
3. mda still assumes that mda is actually an MTA, say,
/usr/sbin/sendmail. This should be fixed or documented, as it breaks
multidrop.
--
Matthias Andree