atom feed13 messages in org.mutt.mutt-usersRe: mailbox close while accessing exc...
FromSent OnAttachments
Jason JoinesNov 30, 2007 12:37 pm 
Jason JoinesNov 30, 2007 2:22 pm 
Kyle WheelerNov 30, 2007 2:37 pm 
Brendan CullyNov 30, 2007 3:10 pm 
Jason JoinesDec 5, 2007 8:40 am 
Jason JoinesDec 5, 2007 8:43 am 
Jason JoinesDec 7, 2007 8:55 am 
Jason JoinesDec 7, 2007 10:16 am 
Brendan CullyDec 7, 2007 11:12 am 
Jason JoinesDec 7, 2007 11:27 am 
Jason JoinesDec 7, 2007 1:30 pm 
AjeetDec 11, 2007 11:33 pm 
Jason JoinesDec 13, 2007 1:54 pm 
Subject:Re: mailbox close while accessing exchange over imap
From:Jason Joines (
Date:Dec 7, 2007 8:55:55 am

Jason Joines wrote:

Kyle Wheeler wrote:


On Friday, November 30 at 02:37 PM, quoth Jason Joines:

The reason I'm working on this in the first place is someone else reported the same problem with an imap_keepalive=300. So, I set up Mutt to connect to the same exchange server and another instance of Mutt to connect to a Courier IMAP 4.1.3 server that I maintain. There have been no problems with the connection to the Courier server just using Mutt's default settings.

Heh, there's a shock: a Microsoft product that plays fast and loose with the IMAP spec.

I normally use Thunderbird 2.0 to connect to the same exchange server and have no problems. However, Thunderbird keeps the message index and headers on local disk even for IMAP mail so it just might not be letting me know that the mailbox is being closed by the server.

Indeed, it probably isn't. Seriously, if you can fake it to hide the network latency, why bother the user with such pithy details? Mutt only does so because it believes in being more honest about what's really going on rather than in providing a pleasant illusion. ;) (That's one way of putting it, anyway---another would be WYSIWYH.)

From the way Mutt reports "Fetching message headers" at startup while it counts through all the messages in my inbox and then displays an empty list when the mailbox goes away, I'm guessing it does not store any sort of index on disk for IMAP messages. Is that correct?

For mutt 1.4.x? Correct. That feature has been added to the development version of mutt (1.5.x) and will be in the next stable mutt (1.6), whenever that comes out.

Any suggestions for other client side tweaks to help with this problem? I don't administer the exchange server and getting those who do to even reveal any settings, much less change them, will be a nightmare.

I guess my first instinct would be to use a *really* low imap_keepalive (like 60), and maybe a timeout value of 1 or something similarly silly and see if that helps.

If it doesn't, I'd be curious to try compiling mutt with debugging enabled (reconfigure with --enable-debug) and then run it with a -d2 argument. That will cause it to log (in ~/.muttdebug0) the entire IMAP conversation, so you can see exactly what's going on. If the previous attempts to fix the problem didn't work, my guess would be that mutt is using the IMAP NOOP command to keep the connection alive, and Exchange is not recognizing that as something that keeps the connection alive. But that's just a guess---the log of the IMAP connection would tell you for certain. At that point you can probably easily figure out what mutt is doing and who's doing something wrong. Chances are there's little you can do to really fix the problem, but it's better to know what the problem is for sure first!

~Kyle - -- The surest way to corrupt a youth is to instruct him to hold in higher regard those who think alike than those who think differently. -- Nietzsche -----BEGIN PGP SIGNATURE----- Comment: Thank you for using encryption!

iD8DBQFHUJCtBkIOoMqOI14RAg4yAKCu/NhGMerQ/1b9ZNmkyYdK7d22XACgn34l yfhjUTxptrhVPdzyXyP+0Ek= =6XIl -----END PGP SIGNATURE-----

I started at 256 for timeout, mail_check, imap_keepalive and kept having them every time the problem occured. Now I'm down to 2 and the problem is better but not gone.

I am going to try your debug suggestion. However, after reading the FAQ entry and thinking about some other odd behavior I've observed with other applications connecting to stuff managed by the same people, I think it may be a firewall isssue.

Jason ===========

I went back to the default settings, tried the debug option and got this output:

Mutt started at Fri Dec 7 10:10:31 2007 . Debugging at level 2.

mutt_alloc_color(): Color pairs used so far: 1 < * OK Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1 ( ready.


< * CAPABILITY IMAP4 IMAP4rev1 IDLE LOGIN-REFERRALS MAILBOX-REFERRALS NAMESPACE LITERAL+ UIDPLUS CHILDREN Handling CAPABILITY < a0000 OK CAPABILITY completed. imap_authenticate: Using any available method. Sending LOGIN command for joines... < a0001 OK LOGIN completed.

a0002 LIST "" ""

< * LIST (\Noselect) "/" "" < a0002 OK LIST completed. Delimiter: /


< * 178 EXISTS Handling EXISTS cmd_handle_untagged: New mail in INBOX - 178 messages total. < * 0 RECENT < * FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent) Getting mailbox FLAGS < * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)] Permanent flags Getting mailbox PERMANENTFLAGS < * OK [UNSEEN 30] Is the first unseen message < * OK [UIDVALIDITY 143157] UIDVALIDITY value < a0003 OK [READ-WRITE] SELECT completed.


BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE IN-REPLY-TO REPLY-TO LINES X-LABEL)]) < * 1 FETCH (UID 3 FLAGS (\Seen) INTERNALDATE "13-Sep-2007 12:22:59 -0600" RFC822.SIZE 35843 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE IN-REPLY-TO REPLY-TO LINES X-LABEL)] {322} Handling FETCH FETCH response ignored for this message imap_read_literal: reading 322 bytes < ) parse_parameters: `boundary="----_=_NextPart_001_01C7F633.1CF61078"' parse_parameter: `boundary' = `----_=_NextPart_001_01C7F633.1CF61078' < * 2 FETCH


< * 178 FETCH (UID 580 FLAGS (\Seen) INTERNALDATE " 7-Dec-2007 08:19:09 -0600" RFC822.SIZE 1561 BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE IN-REPLY-TO REPLY-TO LINES X-LABEL)] {258} Handling FETCH FETCH response ignored for this message imap_read_literal: reading 258 bytes < ) parse_parameters: `charset=us-ascii' parse_parameter: `charset' = `us-ascii' < a0004 OK FETCH completed. imap_open_mailbox: msgcount is 178

a0005 NOOP < a0005 OK NOOP completed. a0006 STATUS "Drafts" (MESSAGES)

< * STATUS Drafts (MESSAGES 4) 4 new messages in imap:// < a0006 OK STATUS completed. mutt_num_postponed: 4 postponed IMAP messages found.

a0007 NOOP

Error talking to (Connection reset by peer) imap_cmd_step: Error reading server response. Mailbox closed imap_exec: command failed:

If I'm interpreting this correctly, the first NOOP worked. An attempt was made to send a second NOOP but the mail server couldn't be contacted. Looks to me like a connection issue instead of a server issue. What do you think?

Jason ===========