On Thu, May 20, 2004 at 02:42:19PM -0700, Clint Sharp wrote:
The RFC States: "The unique identifier of a message MUST NOT change
during the session, and SHOULD NOT change between sessions." SHOULD NOT
change between the sessions is the key word. However, it CAN change,
which means that this is useless in my implementation.
As I read it, the 'CAN change' gives permission for the IMAP server to
recover from a loss-of-state condition (e.g. the file containing the UIDs is
deleted from some reason).
However the IMAP RFCs have been plagued with ambiguities, and even after
several revisions still are...
The comment about disconnected operation makes it pretty clear that the
intention is that UIDs should be persistent between sessions though. If they
are renumbered every time, then effectively they look like completely new
messages each time.
First of all,
it's only guaranteed consistent with the same UIDVALIDITY value.
That's right. If the state information is lost and UIDs have to be
regenerated, you have to ensure that the new numbers which are generated do
not clash with the old numbers (otherwise message X might be misunderstood
to be message Y). UIDVALIDITY ensures that this never happens.
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.
Ah, then UW IMAP doesn't support disconnected operation.
You say you've tried one other IMAP server (Exchange), and it does implement
this properly. I can tell you that courier-imap does too. I would imagine
that actually most IMAP servers support this mode of operation.
(I suppose
UW's implementation would probably be fairly useless for anyone trying
to do offline IMAP as well). This would wreak havoc on fetchmail if the
UID numbers are reallocated, causing us to redownload and re-deliver
email which was already seen and possibly missing mail which was never
seen.
Well, IMAP has more than one mechanism defined to detect this:
- The \Seen flag
- The UID mechanism
I personally don't see a need for a third, as it violates the spirit of the
protocol (i.e. the protocol designers put those features in for a purpose).
Perhaps if fetchmail had a 'plug-in' type architecture then unusual or
specialised configurations like this could be more easily supported.
Regards,
Brian.