On Thursday, 23 September 2010 at 14:13, Michael Elkins wrote:
> On Thu, Sep 23, 2010 at 10:19:28PM +0200, Michael Williams wrote:
> >On 23 Sep 2010, at 19:17, Christian Brabandt wrote:
> >>>4< * 3700 FETCH (UID 17146 FLAGS (\Seen) INTERNALDATE "23-Sep-2010
> >>>09:14:57 +0100" RFC822.SIZE 2612 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO
> >>>CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
> >>>REPLY-TO LINES LIST-POST X-LABEL)] {404}
> >>>4< * 3702 FETCH (UID 17148 FLAGS (\Seen) INTERNALDATE "23-Sep-2010
> >>>14:35:54 +0100" RFC822.SIZE 20548 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO
> >>>CC MESSAGE-ID REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
> >>>REPLY-TO LINES LIST-POST X-LABEL)] {408}
> >>
> >>Here is one missing.
> >
> >Is this the problem? Is there a workaround or is the conclusion that mutt is
> >not compatible with Exchange 2010 IMAP's support (or Exchange 2010 is not
> >compatible with mutt)?
>
> Yes, this is the problem. Mutt expects to see a FETCH response for
> each message the server says EXISTS. The IMAP standard requires that
> no "holes" exist in the message sequence numbers, and mutt is not
> prepared to handle them.
We might be able to work around this by creating an empty message
marked as expunged for the holes, then running the expunge compactor
after the command finishes. But it does seem like there's probably
something wrong with your mailbox on the server side. It might go away
if the exchange server administrator runs some kind of maintenance
tool on the problematic mailbox.
