On Thu, Sep 23, 2010 at 19:09:43 +0200, Michael Williams wrote:
> $ grep 'FETCH' .muttdebug0 | tail
>
[...]
> 4< * 3709 FETCH (UID 17155 FLAGS (\Seen) INTERNALDATE "20-Sep-2010 17:19:34
> +0100" RFC822.SIZE 126689 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)] {451}
> 4< a0011 OK FETCH completed.
>
> With mutt itself stuck at "Fetching message headers... 3630/3709 (97%)".
On Thu, Sep 23, 2010 at 14:13:05 -0700, Michael Elkins wrote:
> 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.
As someone who doesn't know any details about the IMAP standard or
Mutt's internal workings, I'm curious to know what happens once Mutt
sees the "OK" message from the server in this situation.
Is there any way it could use that message to at least abort the fetch
operation with some error message, rather than hanging?
Nathan
