Clint Sharp <clint(_at_)typhoon(_dot_)org> writes:
It is true on the reference IMAP implementation I used (UW IMAP). I
UW Imap is something I stopped using a long time ago,
a decision I've never regretted, not for a single second.
However, UW IMAP implementation doesn't even keep the same UIDVALIDITY
between sessions, even without an expunge or any sort of internal
reordering of the email, as seen by the example at the end of the
email.
That would be a SHOULD violation.
Exchange keeps consistent UID values even after deleting messages and
expunging, but we need to work on the lowest common denominator, which
in my testing was UW. I don't have access to Cyrus or any of the other
popular IMAP servers to test.
I can offer a low-bandwidth Dovecot account for testing if that
helps. Contact me off-list.
already seen and possibly missing mail which was never seen. Also, what
would we do when the UIDVALIDITY value changed? Redeliver all mail?
That would be the obvious yet undesirable solution.
One way to kill duplicates would be to SHA1 or RIPEMD160 all Received:
headers, the Message-ID, Subject, Date, From and To/Cc headers.
I don't mean to contradictory, but I don't see any way IMAP's UID
facilities could possibly work for fetchmail, given the inconsitencies
of the implementation and even the fact that the implementation says
that the unique key (Mailbox+UID+UIDVALIDITY) SHOULD NOT, but can
change.
How about trying the latest UW version, and if the problem persists,
filing a bug report with the UW IMAP team?
* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN]
localhost.localdomain IMAP4rev1 2001.315rh at Thu, 20 May 2004 15:56:44
-0500 (CDT)
2001 looks rather oldish...
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95