On Sat, Aug 21, 2021 at 11:35:19AM +0200, Pieter-Tjerk de Boer via Mutt-dev wrote:
The below patch fixes mutt's IMAP message number handling in case it is started with a header cache in which a mail somewhere "in the middle" is missing (i.e., the cache does contain a mail later than the one that is missing). This bug isn't just cosmetic; it can lead to unintended deletion of large amounts of mails.
I'm very sorry to hear about the loss of email. That's the most terrible bug there can be. :-(
Let me get my head re-familiarized with the IMAP code today, and then I'll take a closer look.
Let me give a step-by-step example of what went wrong and how that could lead to losing mail:
Thank you for the detailed description of the problem. The code comments mentioned holes in the header cache but I never quite understood how they would exist.
Fortunately, fixing this is trivial; at two places in imap/message.c,
replace
ctx->hdrs[idx]->index = idx;
by
ctx->hdrs[idx]->index = h.data->msn-1;
Unfortunately I don't think this is the correct fix. There can in fact be holes in the MSN sequence.
I think a better fix would be changing the sort order to use UID instead when creating the msgset, but I have to take another look at the EXPUNGE code again, to check for interactions.
I also checked what happens if CONDSTORE and QRESYNC are enabled. In that case, verify_qresync() notices that the quick resync didn't work correctly, but the subsequent attempt at a normal resync fails in a different way: it doesn't fetch the headers for the missing mail. To the user, it then looks as if the mail is no longer in the mailbox, even though the server still has it. The below patch fixes this too.
Thank you - good catch. I'll apply this as a separate patch today. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
