Hi,
fetchmail 6.2.5 brought a new fastuidl option, which added a lot of
baggage and deems itself unsafe (it falls back to "slowuidl" for few
mails or in flush mode) in some places.
CURRENT STATE
1. The current UIDL assumes that new messages show up at the end of the
list.
2. We can know how many messages are on the server through STAT. Let
these be in a variable "totalmsgs".
3. We further know how many UIDLs we have seen, by counting the ids. Let
these be in a variable "knownids".
FURTHER CONDITIONS
(may be met, haven't looked)
* Any DELE must be accompanied by dropping the corresponding IDs from
the file AT THE SAME TIME. This ID dropping MUST NEVER be deferred, as
a server is free to reuse the UID (see RFC-1939) - the entity to which
the UID had referred is now gone!
SUGGESTION
* In FastUIDL mode, request UIDL for the interval
[knownids ; totalmsgs].
- If ALL returned UIDs except the first are unseen, we know we have all
mail. Poll completed.
- If ANY of the 2nd to last returned UIDs is known to us, we know that
at least one is in the interval [ 1 ; knownids ] - either we skipped
one (temporary error) or the server inserted the new UID into the
middle of the list, rather than appending it to the end of the list
(*1). Request UIDL 1-totalmsgs.
- If the 1st returned UID (which we should know) is unseen or mismatches
the last previously seen UID, we know a previously seen mail has been
deleted and our counts are off. Request UIDL 1-totalmsgs.
ADVANTAGES
* we don't need to probe (binary search) into the "known" range, and we
can fetch all UIDLs and sizes (through LIST) for new mails in one
round trip, rather than ld(totalmsgs) + (totalmsgs - knownids) round
trips.
* still the speed-up we got from the binary search
QUESTIONS
Can anyone think of a scenario where wild deletion and arrival of new
mails into random places (not end of the list) can deceive the method I
show above? I can think of scenarios that recycle UIDs _AND_ stuff them
into the middle of the UID list.
FOOTNOTES
*1: some older Courier[-IMAP] servers are _known_ do to this
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95