POP3 supports three
POP3 has one - UIDL.
Prehistoric POP3 (RFC1460) had another - LAST ...
I'm not aware of any other.
LAST, FastUIDL, SlowUIDL. FastUIDL uses the POP3 UIDL command, slow
UIDL uses TOP to parse for Message-ID headers ... My proposal
would be to implement a similar functionality in the IMAP driver (\Seen,
Fast UIDL/Slow UIDL), however, we cannot easily detect broken IMAP
implementations unless we somehow determine if we've crossed some
treshhold of UIDVALIDITY changes over a period.
I'd be willing to remove the Slow UIDL code (MD5 checksum of Received
and Message-ID headers) if that's the consensus. However, it already
works and would work on nearly any (even broken) IMAP implementation, so
it seems like it'd be better to hide it behind a configuration option
than remove it completely.
Clint
I'm not convinced that we need either breakage detection or a config
option (unless there is an IMAP so broken that it does not change its
UIDVALIDITY when changing UID's).
Given that the UID's are supposed to be persistent unless UIDVALIDITY
changes, I would think that fetchmail can automatically decide whether
to do Fast or Slow UIDL during any given session:
* On first session, use Slow UIDL to establish a baseline; save the
UIDVALIDITY, UID's, and corresponding MD5's along with "already
delivered" status. Slow UIDL is essentially free this time,
because we are going to fetch and deliver everything anyway; we
can compute the MD5's while fetching for delivery.
* Whenever UIDVALIDITY matches the saved value, use Fast UIDL.
* Whenever UIDVALIDITY changes, use Slow UIDL and the saved MD5's to
update the saved UID's.
This way, we only have to refetch and rehash previously-seen headers
when the UIDVALIDITY changes. If we happen to run into a server which
changes it every session, we'll automatically use Slow UIDL for every
session.