[Dovecot] critical X-UID reordering problem after upgrade from 1.1 to 1.2

[Rob Henderson]

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
1) 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: 59665

So, 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