Re: Returning to ticks on read-only imap servers

[Michael Welsh Duggan <md5i@md5i.com>]

Julien Danjou <julien@danjou.info> writes:

> On Fri, Oct 08 2010, Dan Christensen wrote:
>
>> I'm no expert, but my understanding is that in normal operation,
>> UIDVALIDITY never changes, even when messages arrive, are deleted, or
>> flags change.  So it can't help solve the problem at hand.
>
> That's totally the opposite. A UIDVALIDITY number design a mailbox in a
> state. If any change occurs, the UIDVALIDITY number changes. That's how
> you know you need to do a FETCH 1:* to resynchronize your (cached)
> version of the mailbox.
>
> Read section 2.3.1.1 of RFC3501.

After re-reading that section, I think you are mistaken.  UIDVALIDITY is
guaranteed not to change as long as the messages in the mailbox have not
changed their UIDs (or rather, as long as the mailbox maintains its
identity).  It does not change with the addition, or deletion, of
messages to that mailbox.  On the other hand, the UIDNEXT does change
with the addition of new messages to the mailbox.  It will not, however,
change with the deletion of messages.  The triple of mailbox name,
UIDVALIDITY, and message UID will always refer to the same message no
matter what, as long as that message still exists.

"First, the next unique identifier value MUST NOT change unless new
 messages are added to the mailbox; and second, the next unique
 identifier value MUST change whenever new messages are added to the
 mailbox, even if those new messages are subsequently expunged."

In the above extract, the "next unique identifier value" refers to
UIDNEXT, not UIDVALIDITY.

-- 
Michael Welsh Duggan
(md5i@md5i.com)