On Mon, 2003-01-20 at 00:19, Andreas Aardal Hanssen wrote: > You agree that the problem arises if the same mailbox has the same > UIDVALIDITY two times in history in such a way that the same UID referes > to two different messages. > > Then you say that this can never occur if the UIDVALIDITY is always > different. True, but how can you make sure that this is the case?
Simple. Use a global or user-global UIDVALIDITY counter. How exactly that is done is implementation problem. I was thinking of a .uidvalidity file which contains it. It would initially begin with time(), but after that it would grow one at a time. That way it wouldn't really matter if the file itself had to be recreated, and it also wouldn't matter if client created multiple mailboxes within one second. > >If they do need to grow, server would have to remember the last > >UIDVALIDITY for deleted mailboxes, so RENAME could check if the > >UIDVALIDITY must be changed. I don't like that behaviour. It's very > >unnecessary and requires permanent space for deleted mailboxes. > > Exactly! Which is why the RFC recommends the use of UNIX time > (time(NULL)), in which case it is unnecessary to remember any previous > values. Uhm. Did you forget how this thread started? :) CREATE a -> UIDVALIDITY == time() == eg. 1234 CREATE b -> UIDVALIDITY == time() == eg. 1235 .. use both mailboxes .. DELETE b RENAME a b Now b's UIDVALIDITY is 1234, which is less than the previous 1235. Meaning it's not conforming to the IMAP spec. Even worse if the mailboxes were created at exactly the same time. > The point is that the RFC has good reason to require this behavior on the > server side, and any server that does not follow this requirement is > broken and needs to be fixed. I believe none of the common IMAP servers handle the above situation "correctly".
