Quoting from Rob Funk's mail on Sat, Oct 11, 2003 at 11:04:56AM -0400:
Sunil Shetye wrote:
- If some of the retrieved mails had delivery problems (say, due to
transient SMTP error), those mails never get downloaded again in
further polls. Note that the seen flag is set here automatically as
the mail was downloaded successfully.
Isn't this why fetchmail uses TOP instead of RETR?
TOP is not used with 'keep'. If TOP is used when 'keep' is on, no mail
will get marked as seen, and LAST will always return 0.
- If some of the mails get skipped (not retrieved at all) for some
reason (say, due to 'limit'), the mails never get downloaded.
Caveat emptor if using --limit on a LAST-only server.
Why use LAST anyway? UIDL assures that even skipped mails will get
downloaded if and when the options change later to allow such mails.
- If there is a socket error, the POP3 server may revert the state of
the mailbox. The output of LAST will not then change in the next
poll. So, all the mails that were downloaded & delivered
successfully will get redownloaded in the next poll.
Better than losing mail...
UIDL assures that each mail is downloaded and delivered exactly once.
With UIDL, there cannot be loss of mail. Even if there is a socket
error and even if the POP3 server reverts the state of the mailbox,
the delivered mail will not be redownloaded!
Though one ugly fix would be to exit and re-login to the server between
each message download.
UIDL does not require such an ugly fix.
So, the only sane option left is UIDL. Matthias Andree is right!
Inspite of the complexity required in tracking new mails, UIDL is
infact quite a safe and secure method for tracking new mails.
Unless you ever use other clients besides fetchmail with that server.
I don't think it's so unreasonable to do so.
IMO, all other clients do use UIDL.
In fact, the "delete after X days" feature seen in many clients is
probably done using UIDL. Each UID is saved locally with a timestamp.
When the UID becomes X days old, the corresponding mail is deleted.
[In fact, I am wary of the script by James Stone which claims to
implement the "delete after X days" feature without local timestamps.
If the script is going to rely on the timestamps in the headers, any
unknown header change by the server could lead to loss of mail.
I would prefer if the format of the fetchids file is changed to
include the time of download with each uid.]
If a server does not support UIDL, the only safe retrieval is by using
fetchall. Using LAST even as a backup is not recommended due to the
problems mentioned above.
Which totally screws those who want to use other clients besides fetchmail.
If fetchmail and the other clients are all using LAST only, reliable
delivery by each client cannot be expected anyway!
Say, you have 10 new mails (no old mail) in your mailbox. Using an
interactive email client, you just read the 9th mail. This means that
LAST is now going to return 9 for all the other clients (including
fetchmail) who will then think that only the 10th mail is new!
Well, the slow UIDL (which works by using the message-id of each mail
as a UID) is an option. It will work when UIDL is not supported. There
are however two hidden problems with this:
- message ids may not be unique in multidrop mode.
- the user may not be aware of the extra bandwidth required for slow
UIDL. The current code defaults to slow UIDL if UIDL is not
supported. Instead it should be an option making the user aware of
the side effects.
--
Sunil Shetye.