Dovecot IDLE problem (was Re: [Dovecot] inotify support in dovecot)
Hi,
I've come across some possibly buggy behaviour with regards to Dovecot and the use of the IDLE keyword. Found this while testing out inotify support for Johannes - although after asking him and him reproducing it, he is of the opinion that it's not a inotify specific problem.
The behaviour is that when the client is idling, Dovecot seems to only alert to the first new message received, and if a subsequent new message comes in before the client finishes idling, that second new message is not notified to the connected client.
To reproduce:
$ maildirmake /tmp/imap-test
$ cat >/tmp/1 < test!
<Ctrl-D>
$ MAIL=Maildir:/tmp/imap-test /usr/libexec/dovecot/imap
...
A SELECT INBOX
B IDLE [now, in a different terminal, copy /tmp/1 to /tmp/imap-test/new, you
should instantly be notified of it in your imap session] ** Dovecot correctly responds with: [if a second message is delivered, eg by copying /tmp/1 to
/tmp/imap-test/new/2 then you should be notified as well, but this never occurs] DONE
C LOGOUT
$ Timo - what do you think? Reuben
--On Thursday, August 18, 2005 10:47 PM +1200 Reuben Farrelly reuben-dovecot@reub.net wrote:
[if a second message is delivered, eg by copying /tmp/1 to /tmp/imap-test/new/2 then you should be notified as well, but this never occurs]
Is that true? I would think you only want notification one time after each new command (eg. IDLE), to indicate that the client is out-of-date wrt the server. It's essentially a "cache dirty" notification. It's then the client's job to bring itself up to date with the server state, at which point a new notification is appropriate.
BTW, does IMAP provide any notification ability for folders other than INBOX? I deliver via procmail to other folders and I believe Mulberry has to poll them periodically to check for new mail. (Different mailing lists and different friends each get their own folder.) Doing my filtering server-side means I don't need to maintain parallel filters on all my clients, on all the systems I use. (I gotta get around to doing the same for my address book, setting up an LDAP server.)
On Thu, 2005-08-18 at 06:02 -0700, Kenneth Porter wrote:
Is that true? I would think you only want notification one time after each new command (eg. IDLE), to indicate that the client is out-of-date wrt the server. It's essentially a "cache dirty" notification. It's then the client's job to bring itself up to date with the server state, at which point a new notification is appropriate.
Not sure about that. However, you get the same behaviour if you abort and re-issue the IDLE (up to a certain time or something).
BTW, does IMAP provide any notification ability for folders other than INBOX? I deliver via procmail to other folders and I believe Mulberry has to poll them periodically to check for new mail. (Different mailing lists and different friends each get their own folder.) Doing my filtering server-side means I don't need to maintain parallel filters on all my clients, on all the systems I use. (I gotta get around to doing the same for my address book, setting up an LDAP server.)
Yes, but only for the folder that is currently selected. And since you cannot select more than one... I think it would be within the spec to simply send an unsolicited response for any folder at any time, but I'd have to check and clients wouldn't use it anyway.
johannes
--On Thursday, August 18, 2005 3:35 PM +0200 Johannes Berg johannes@sipsolutions.net wrote:
BTW, does IMAP provide any notification ability for folders other than INBOX? I deliver via procmail to other folders and I believe Mulberry has to poll them periodically to check for new mail. (Different mailing lists and different friends each get their own folder.) Doing my filtering server-side means I don't need to maintain parallel filters on all my clients, on all the systems I use. (I gotta get around to doing the same for my address book, setting up an LDAP server.)
Yes, but only for the folder that is currently selected. And since you cannot select more than one... I think it would be within the spec to simply send an unsolicited response for any folder at any time, but I'd have to check and clients wouldn't use it anyway.
The hard part is defining the interaction as an extension and getting it into a standard.
A lot of mail providers (ie. ISP's) are now providing a spam and virus quarantine folder, so IMAP becomes more useful to end users, and the ability to get notifications on additional folders becomes more relevant.
(I should check with SquirrelMail to see if it has an extension to define server-side filters. Last I checked, it doesn't have anything to check unsubscribed folders for new mail, though. Mulberry will poll for that, using a wildcard folder spec.)
On Fri, 2005-08-19 at 13:38 -0700, Kenneth Porter wrote:
The hard part is defining the interaction as an extension and getting it into a standard.
I agree. But it'd be nice to see this. The technology has advanced enough (inotify etc.) so that it would be feasible to get notifications for hundreds of users with tens of folders each (inotify is really cheap as compared to dnotify for example).
A lot of mail providers (ie. ISP's) are now providing a spam and virus quarantine folder, so IMAP becomes more useful to end users, and the ability to get notifications on additional folders becomes more relevant.
Absolutely.
(I should check with SquirrelMail to see if it has an extension to define server-side filters. Last I checked, it doesn't have anything to check unsubscribed folders for new mail, though. Mulberry will poll for that, using a wildcard folder spec.)
Not that I know of (in squirrelmail). But squirrelmail is a bit of a corner case anyway since it doesn't keep an online connection, it reconnects all the time.
johannes
On Thu, 2005-08-18 at 22:47 +1200, Reuben Farrelly wrote:
The behaviour is that when the client is idling, Dovecot seems to only alert to the first new message received, and if a subsequent new message comes in before the client finishes idling, that second new message is not notified to the connected client.
It is notified, just not immediately. And it's intended to work like that. If Dovecot tells the client about a new message and it doesn't care enough about it enough to break IDLE, it doesn't need to know about the second message immediately either.
Although I suppose with clients that use a second connection to read the new mails this kind of behavior isn't exactly wanted.. Well, I'd like to know if such clients exist before changing this.
- 1 EXISTS
- 1 RECENT
[if a second message is delivered, eg by copying /tmp/1 to /tmp/imap-test/new/2 then you should be notified as well, but this never occurs]
It should occur in 30-60sec or so.
participants (4)
-
Johannes Berg
-
Kenneth Porter
-
Reuben Farrelly
-
Timo Sirainen