On Tue, 26 Sep 2006, Andrew Daviel wrote:
However, some users using Thunderbird report funny things, e.g.
"When I go to a folder I have not yet looked at since imapd was changed, it
always reports double the number of messages. If I go to any other folder and
come back to this first one, the number of messages comes back to normal."
I think that the UIDs in the mailbox got rebuilt (which resulted in a new
local cache of messages), but Thunderbird didn't clear out its old cache
completely until the user went to another mailbox and came back.
As for why the UIDs got rebuilt:
imap-2006 supports the UIDPLUS extension (RFC 4315), which requires that
UIDs be assigned when messages are delivered. A certain client does not
work with servers that do not have UIDPLUS. ;-(
UIDs (Unique IDentifiers) are strictly ascending in the mailbox. This is
a requirement of RFC 3501.
Prior to UIDPLUS, messages were delivered without a UID assigned, and the
UID would be assigned when the mailbox was next opened. Now, UIDs must be
assigned immediately upon delivery.
The problem comes in if messages are added under the new rules to a
mailbox which still has some messages that do not have assigned UIDs (old
rules). The new delivery process will assign UIDs based upon the UIDNEXT
metadata value in the mailbox; but that value has not been updated to
account for the other messages without assigned UIDs. Then, when the
mailbox is opened, the messages without UIDs get UIDs assigned based upon
the UIDNEXT value. That goes well, until we encounter the (later) messages that
were delivered under the new rules and a lower UID value. Since UIDs must
be ascending, those UIDs are wrong, and the UIDs have to be rebuilt.
In theory, this should only happen to some (not all) mailboxes that got
into the situation described above; and once a rebuild has happened it
should not need to happen again.
If a rebuild happens repeatedly on the same mailbox, I want to know about
it. However, make sure that there isn't any software that is adding
messages to the mailbox under the old rules. In particular, I believe
that some versions of procmail and/or postfix know about mbx mailboxes,
and use their own code rather than c-client library code.
I had also seen some user folders which worked OK under 2004, being slow
or failing under 2006. When examined with Pine linked against 2006 c-client,
Pine may report "Invalid UIC in message nnn, rebuilding".
"Invalid UID", not "Invalid UID".
Does the rebuild happen multiple times for the same mailbox, or just once?
Or my "mbxfix" script may find errors. Is the new code more sensitive to
errors in the MBX file ?
It shouldn't be more sensitive, but this UIDPLUS stuff does add additional
complexity.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
