Timo Sirainen wrote:
One easy solution would be to change UIDVALIDITY (the large number in X-IMAP: or X-IMAPbase: header) of each mailbox. Then the client will redownload all mails.
This is what I ended up doing (just inc'ing the current UIDVALIDITY by
- and that seems to have worked for our IMAP users. However, this is more problematic for the pop users since it looks like that causes every message in the inbox to appear to be new (the new %v yields all new UIDLs so all the messages look like ones the client hasn't seen). I suppose it serves them right for using pop... ;-)
I can't really think of why UIDs would have changed though. I think v1.1's and v1.2's mbox handling code is pretty much the same.
I think I may have identified the problem. I have a test inbox that is very repeatably munged by dovecot 1.2.4 the first time it is accessed. The thing I noticed about it is that it has:
X-IMAPbase: 1076423160 0000059291 Junk $Label1 $Label3 $Label5 NonJunk $Forwarded $MDNSent $Label2 $Label4
However, the last message (with the largest X-UID) is:
X-UID: 59665So, this UID 59665 is larger than last used UID on the X-IMAPbase line! I have to assume this is a bad thing, right? As a test, I changed the X-IMAPbase: line and set the last used UID properly and that was all it took to prevent dovecot from doing the reordering.
But, how did this happen? I know it was like this on several inboxes (maybe even most of them) and we had been running dovecot 1.1.3 previously for quite a while. So, was this a bug in 1.1.3? And, perhaps more importantly for others who may hit this same problem, is there some way that 1.2.x can recognize this condition and compensate for it without doing the really nasty reordering?
Thanks!
--Rob