On 19 Jan 2003, Timo Sirainen wrote: >On Sun, 2003-01-19 at 21:30, Alexey Melnikov wrote: >> > RENAME a b >> > CREATE a >> > DELETE a >> > RENAME b a >> Ideally each server must preserve UIDVALIDITY on RENAME, until an older >> incarnation of the same mailbox had a bigger UIDVALIDITY. >> (In reality most of the servers do the first part, but not the second). In the >> latter case the server has to assign a new UIDVALIDITY bigger than >> max (current_uidvalidity, previous_uidvalidity). >I don't see any requirement for UIDVALIDITY to grow. Probably easiest >way to handle this would be to guarantee a different UIDVALIDITY for >each created mailbox, then it wouldn't matter how they were renamed. >Using timestamp as UIDVALIDITY works pretty well in practise, unless >client creates multiple mailboxes at once. Hmm. Wonder if I should >bother fixing this in my server..
I'm not quite sure wether you understand the problem or not. If you create one mailbox A and give it UIDVALIDITY 1, then rename it to B, and leave it. Now create a mailbox A again and give it UIDVALIDITY 2, which is perfectly fine and similar to giving it UIDVALIDITY = time(NULL). 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. 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. Andy -- Andreas Aardal Hanssen
