On 19 Jan 2003, Timo Sirainen wrote: >On Sun, 2003-01-19 at 22:28, Andreas Aardal Hanssen wrote: >> If you then delete A and rename B back to A, you will have a mailbox A >> that in the client's POV has _decreased_ its UIDVALIDITY. >Like I said, I don't see any requirement for UIDVALIDITY to _grow_. It >has to be _different_.
Then you should read the fine manual: ftp://ftp.uninett.no/pub/rfc/rfc2060.txt line 415: "If unique identifiers from an earlier session fail to persist to this session, the unique identifier validity value MUST be greater than the one used in the earlier version." Can't get any clearer than that! >> This means that a message that the client saw in A earlier may now >> reappear in A with a different UID, but the UIDVALIDITY may be the same or >> lower. Or the message that the client earlier identified as 1:1 is now 1:5 >> (UIDVALIDITY:UID), and that's in breach with the protocol. >That happens only if the UIDVALIDITY is exactly the same. There should >be no problem if it's lower, or the client is broken (or I've missed >something in the specs). So the IMAP server should keep track of all UIDVALIDITY values that a mailbox has had throughout history? There's only one clean way to avoid doing that, which is to assign them in strictly ascending order. My quick guess would be that this is the reason that it's so. Andy -- Andreas Aardal Hanssen - Binc IMAP http://www.bincimap.andreas.hanssen.name/
