Kyle Wheeler wrote: [Tue Mar 21 2006, 12:50:21PM EST] > Mutt, then, relies on the server to report this new message, > presumably because it needs the unique MSGID number for it that must > be generated by the server (this is again, an artifact of the IMAP > protocol that allows messages to be referred to and cached on > a semi-permanent basis). When you tell mutt to do an > “imap-fetch-mail”, what mutt *actually* does is sends a NOOP command > to the server. Most servers take that opportunity to reply with > notification of all the new messages in the mailbox since the last > time the client sent a NOOP. Apparently, your server does not do > this (I haven’t checked the specs to find out who is right on this > detail). I'm pretty sure this part works correctly since the more serious issue only appears when header caching is enabled. > In order to get mutt > to do a full SELECT and re-fetch all message IDs, currently, you have > to go through the change-folder mechanism (though you don’t have to go > to another folder and come back, you can just change-folder to the > current folder). > > If I remember correctly, mutt supports the ^ character to refer to > “this folder”, so you could make a macro (I haven’t tested this) like > as follows to do a more thorough (and rather inefficient) > imap-fetch-mail: > > macro index i "<change-folder>^<enter>" "thorough imap-check-mail" I appreciate the temporary workaround, but I'm more interested in getting mutt fixed to handle this situation better. Aron
Attachment:
pgpucTbjp7PYh.pgp
Description: PGP signature