[Dovecot] needing UNSELECT to notice new mail?
I am running
NetBSD/i386 3.1ish and 4.0ish
dovecot 1.0.0 procmail delivering into maildirs
gnus from CVS head emacs 21.4
thunderbird 2 gnome mail-notification 4
configured to required SSL.
Basically everything works fine except that in gnus typing 'g' in the *Group* buffer, which is supposed to check for new mail and list the number of new messages, fails to notice new mail.
Notably, gnus does not do an UNSELECT or CLOSE when it is done with a group.
So basically the following sequence of commands
SELECT "INBOX" blah blah EXPUNGE
STATUS "INBOX" shows no unseen but really there is one
With
(setq nnimap-need-unselect-to-notice-new-mail t)gnus will do UNSELECT before STATUS, and then things work fine.
Another gnus user reports what seems like the same problem with Courier IMAP.
So, is dovecot complying with the IMAP spec here? Is there some notion of a transaction bracketed by SELECT/{UNSELECT,CLOSE}, and is that using something like READ COMMITTED isolation so that it doesn't see messages added by other transactions?
Or should dovecot be not relying on cached state and revalidate the mailbox on STATUS, even if it is already SELECTED?
Further, is it the group's opinion that a well-behaved client would UNSELECT or CLOSE when the user takes an action that indicates being finished with a mailbox? Or is it reasonable to leave a mailbox SELECTed as an optimization. It seems that for Thunderbird, etc., the user sits in INBOX with IDLE, but with gnus I tend to be in *Group* with no mailboxes selected.
On Thu, 2007-05-24 at 08:48 -0400, Greg Troxel wrote:
Basically everything works fine except that in gnus typing 'g' in the *Group* buffer, which is supposed to check for new mail and list the number of new messages, fails to notice new mail.
Show me the IMAP traffic logs and ls -ld output of the Maildir/new directories before and after the mail lookup check.
Or should dovecot be not relying on cached state and revalidate the mailbox on STATUS, even if it is already SELECTED?
Dovecot checks if new/ or cur/ directory's mtime changed. If neither did, it trusts its cached state (basically, there's another dirty-recheck-rule).
Further, is it the group's opinion that a well-behaved client would UNSELECT or CLOSE when the user takes an action that indicates being finished with a mailbox? Or is it reasonable to leave a mailbox SELECTed as an optimization. It seems that for Thunderbird, etc., the user sits in INBOX with IDLE, but with gnus I tend to be in *Group* with no mailboxes selected.
Leaving mailbox selected and IDLEing there (or not) is ok. In general Dovecot doesn't try to enforce any specific kind of client behavior.
On Thu, 2007-05-24 at 16:03 +0300, Timo Sirainen wrote:
Or should dovecot be not relying on cached state and revalidate the mailbox on STATUS, even if it is already SELECTED?
Dovecot checks if new/ or cur/ directory's mtime changed. If neither did, it trusts its cached state (basically, there's another dirty-recheck-rule).
Ah, right. I tested it immediately after replying and looks like STATUS for a selected mailbox is a bit special. It doesn't synchronize the mailbox before or after the lookup. I'm not sure if there's a reason for this, but this most likely won't get fixed for v1.0.x.
So perhaps I should change my words a bit :) A well behaving client should keep track of the mailbox state of the selected mailbox. Instead of doing a STATUS (or UNSELECT+STATUS) you should just do NOOP or IDLE there all the time, and keep track of the STATUS elements you're interested in yourself instead of asking what you already should know..
On Thu, 2007-05-24 at 16:08 +0300, Timo Sirainen wrote:
On Thu, 2007-05-24 at 16:03 +0300, Timo Sirainen wrote:
Or should dovecot be not relying on cached state and revalidate the mailbox on STATUS, even if it is already SELECTED?
Dovecot checks if new/ or cur/ directory's mtime changed. If neither did, it trusts its cached state (basically, there's another dirty-recheck-rule).
Ah, right. I tested it immediately after replying and looks like STATUS for a selected mailbox is a bit special. It doesn't synchronize the mailbox before or after the lookup. I'm not sure if there's a reason for this, but this most likely won't get fixed for v1.0.x.
Sorry for the mail flood :) So the above means that Dovecot replies with STATUS the current known mailbox state. So for example "NOOP + STATUS" will reply the latest changes, but simply doing STATUS won't change anything. I'm not sure what your original example about EXPUNGE + STATUS meant, because that should have shown the current state after the EXPUNGE.
And then some choice quotes from RFC 3501:
It does not change the currently selected mailbox, nor does it
affect the state of any messages in the queried mailbox (in
particular, STATUS MUST NOT cause messages to lose the \Recent
flag).This is probably why Dovecot doesn't synchronize the mailbox. Synchronizing it would lose the \Recent flags. Although this probably wasn't intentional when writing the above, I think it would still be wrong for server to do that. It's a pretty clear MUST NOT there.
Note: The STATUS command is intended to access the
status of mailboxes other than the currently selected
mailbox. Because the STATUS command can cause the
mailbox to be opened internally, and because this
information is available by other means on the selected
mailbox, the STATUS command SHOULD NOT be used on the
currently selected mailbox.Right. What I said. You don't need it.
The STATUS command MUST NOT be used as a "check for new
messages in the selected mailbox" operation (refer to
sections 7, 7.3.1, and 7.3.2 for more information about
the proper method for new message checking).So gnus is breaking a "MUST NOT" from the RFC.
Timo Sirainen <tss@iki.fi> writes:
Note: The STATUS command is intended to access the status of mailboxes other than the currently selected mailbox. Because the STATUS command can cause the mailbox to be opened internally, and because this information is available by other means on the selected mailbox, the STATUS command SHOULD NOT be used on the currently selected mailbox.Right. What I said. You don't need it.
The STATUS command MUST NOT be used as a "check for new messages in the selected mailbox" operation (refer to sections 7, 7.3.1, and 7.3.2 for more information about the proper method for new message checking).So gnus is breaking a "MUST NOT" from the RFC.
Thanks. I've pointed the gnus list at your message and suggested that the unselect-before-checking variable be set to t by default.
participants (2)
-
Greg Troxel
-
Timo Sirainen