On Mon, Aug 23, 2021 at 10:48:59AM +0200, Oswald Buddenhagen wrote:
On Sun, Aug 22, 2021 at 06:35:46AM -0700, Kevin J. McCarthy wrote:I agree the server wasn't behaving nicely. It simply omitted some of the headers. (Probably they were deleted at some point between the "assembly" of the mailbox on its side and sending all the headers - the mailbox was very large and changing constantly I think.) However the MSNs didn't repeat or exceed the initial max MSN reported, so I think it might be debatable if it was broken.unless the problem was misdiagnosed due to mutt's tracking of unsolicited EXPUNGE and EXISTS responses being actually broken,
No, I remember going through the log. It was during the initial connect header FETCH. There were gaps in the result sequence numbers, e.g. 1, 2, 3, 5, 6, 8, 9,.... There weren't any EXPUNGE responses (which would have been illegal during the FETCH processing in any case.)
that server would be most definitely broken. there is absolutely no wiggle room here.
Okay, that's clear enough, and I believe you. :-)So, Pieter-Tjerk, perhaps I'm being too strict about the index assignment then. Again, I don't want to make that change for stable, (and in any case I think we should be sorting by UID to prevent any other possible issues like this in the future). But let me take a second look for master.
My concern is violating that general assumption that index is in the range of 0..msgcount-1. The other mail backends make use of that, but that's independent of the IMAP code of course.
I looked at the Index Menu usage a while ago, and I think I came to the conclusion it might be safe, but there was some ambiguous usage in there. I will take a second look at that.
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
