Re: mailbox close while accessing exchange over imap
Jason Joines wrote:
Kyle Wheeler wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 1.4.2.3i 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 (exfe01.ad.okstate.edu) ready.
> a0000 CAPABILITY
< * 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: /
> a0003 SELECT "INBOX"
< * 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.
> a0004 FETCH 1:178 (UID FLAGS INTERNALDATE RFC822.SIZE
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
<snip></snip>
< * 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://mail.okstate.edu/Drafts
< a0006 OK STATUS completed.
mutt_num_postponed: 4 postponed IMAP messages found.
> a0007 NOOP
Error talking to mail.okstate.edu (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
===========