-----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-----