[Dovecot] Not getting new mail notification
Hey all,
I'm having no luck getting new mail notification except in two mail folders (using maildir w/procmail delivery). I'm using three different clients (sylpheed-claws 1.9.14, Thunderbird 1.5.0.5 and a newer version of Horde). None of them are getting new mail in any except these two folders (inbox and 1 other). If I browse to the folders, still nothing.
If I browse to the folders with Horde, I see the new mail, but not always in the other clients. It's hit or miss if the other clients get notified of the mail, but the mail is moved from the new folder.
I'm subscribed to the folders and have them to be checked for new messages (in Thunderbird).
I tried using dnotify, and things got worse (no folders updated). I've over 350 e-mails sitting in new folders right now:
[robert@thunder Maildir]$ ls .*/new | wc 397 332 12925
One interesting item I noticed is that if I touch a file in a new directory (or vi it), I immediately get notification of the mail (and it gets moved from new to cur).
I'm running dovecot 1.0 RC7 configured as
./configure --sysconfdir=/etc/dovecot --with-pgsql --with-pam --localstatedir=/var
with the following changes to the config:
base_dir = /var/lib/dovecot/ protocols = imaps ssl_cert_file = /etc/ssl/dovecot/certs/dovecot.pem ssl_key_file = /etc/ssl/dovecot/private/dovecot.pem default_mail_env = maildir:%h/Maildir verbose_proctitle = yes protocol imap { imap_client_workarounds = tb-extra-mailbox-sep }
I'm running dovecot through xinetd:
service imaps { disable = no socket_type = stream protocol = tcp wait = no user = root server = /usr/local/libexec/dovecot/imap-login flags = IPv4 server_args = --ssl }
Linux thunder.logicalchaos.org 2.6.12-12-3 #5 SMP Wed Feb 1 23:59:03 MST 2006 i686 AMD Athlon(tm) MP 2600+ unknown GNU/Linux
Help?
Thanks, Rob
Hi,
maybee nothing to do with your case, but with my Thunderbird / Dovecot setup, I had to enable "check this folder for new messages" in all the folders I wanted to monitor within TB.
Charles Robert Creager wrote:
Hey all,
I'm having no luck getting new mail notification except in two mail folders (using maildir w/procmail delivery). I'm using three different clients (sylpheed-claws 1.9.14, Thunderbird 1.5.0.5 and a newer version of Horde). None of them are getting new mail in any except these two folders (inbox and 1 other). If I browse to the folders, still nothing.
If I browse to the folders with Horde, I see the new mail, but not always in the other clients. It's hit or miss if the other clients get notified of the mail, but the mail is moved from the new folder.
I'm subscribed to the folders and have them to be checked for new messages (in Thunderbird).
I tried using dnotify, and things got worse (no folders updated). I've over 350 e-mails sitting in new folders right now:
[robert@thunder Maildir]$ ls .*/new | wc 397 332 12925
One interesting item I noticed is that if I touch a file in a new directory (or vi it), I immediately get notification of the mail (and it gets moved from new to cur).
I'm running dovecot 1.0 RC7 configured as
./configure --sysconfdir=/etc/dovecot --with-pgsql --with-pam --localstatedir=/var
with the following changes to the config:
base_dir = /var/lib/dovecot/ protocols = imaps ssl_cert_file = /etc/ssl/dovecot/certs/dovecot.pem ssl_key_file = /etc/ssl/dovecot/private/dovecot.pem default_mail_env = maildir:%h/Maildir verbose_proctitle = yes protocol imap { imap_client_workarounds = tb-extra-mailbox-sep }
I'm running dovecot through xinetd:
service imaps { disable = no socket_type = stream protocol = tcp wait = no user = root server = /usr/local/libexec/dovecot/imap-login flags = IPv4 server_args = --ssl }
Linux thunder.logicalchaos.org 2.6.12-12-3 #5 SMP Wed Feb 1 23:59:03 MST 2006 i686 AMD Athlon(tm) MP 2600+ unknown GNU/Linux
Help?
Thanks, Rob
-- Charles Bueche charles@bueche.ch sand, snow, wave, wind and net -surfer
Charles Bueche wrote:
Hi, maybee nothing to do with your case, but with my Thunderbird / Dovecot setup, I had to enable "check this folder for new messages" in all the folders I wanted to monitor within TB.
Don't think so. I have that option checked, but it doesn't help. When I run the script below on the Linux server, I get all my e-mail from all my folders. To me, this says it's a Dovecot problem (or my setup/usage of it). The TB client is on a windows machine.
[robert@thunder Maildir]$ cat !$ cat ../bin/doveKick.sh #!/bin/bash
find /home/robert/Maildir -type d -name new -exec touch {}/doveKick \; find /home/robert/Maildir -type f -name "doveKick*" -exec rm {} \;
Thanks, Rob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 13 Sep 2006, Robert Creager wrote:
Don't think so. I have that option checked, but it doesn't help. When I run the script below on the Linux server, I get all my e-mail from all my folders. To me, this says it's a Dovecot problem (or my setup/usage of it). The TB client is on a windows machine.
cat ../bin/doveKick.sh
Do the timestamps of the directories change, when you get new mail? Did you searched the mail archive for inotify/dnotify problems?
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iQEVAwUBRQgMui9SORjhbDpvAQL3rQf/UKEYj2skVAOQQ8HroySQ2DKWpuNytO/Y Rgw3sdaqUAtx1NsFymWhJ/S3ZN5UAjvpXXgQQ8r6AgSE5FpGH6SFCCz5svYR9juQ FejhyTSmsIabNR1vPFTwOjeBPepYMKhP8wbO14uSolT0JZ6tMx8Hy1Bbk4EQBL0g EN5Lm/uj5PVrI3wO9fEW/eLeJJEiM82hKwv71sGPvT81n7Tom0DIpJESM1VXanAH 5ju2IaYsXg26QbEty+Vu52iKjO8sCa1cYENRMLzwMCpAYQZ8ewPoS+RzJEGwPXh4 EYZBls7W3ua46EMsT0DERvs8K0xbjPXLOuyhe3rPSlpIymBhXWChBQ== =ai3L -----END PGP SIGNATURE-----
Steffen Kaiser wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 13 Sep 2006, Robert Creager wrote:
Don't think so. I have that option checked, but it doesn't help.
When I run the script below on the Linux server, I get all my e-mail from all my folders. To me, this says it's a Dovecot problem (or my setup/usage of it). The TB client is on a windows machine.cat ../bin/doveKick.sh
Do the timestamps of the directories change, when you get new mail? Did you searched the mail archive for inotify/dnotify problems?
Bye,
No, they don't change: From dspam Wed Sep 13 08:32:03 2006 Subject: Re: [GENERAL] Template1 oops Folder: .PostgreSQL.General/new/1158157923.13449_0.thunder.logicalch 6091
[robert@thunder Maildir]$ ll -d .PostgreSQL.General/new drwx------ 2 robert users 8 Sep 13 07:57 .PostgreSQL.General/new/
ll -a .PostgreSQL.General/new/ total 16 drwx------ 2 robert users 8 Sep 13 07:57 ./ drwx------ 5 robert users 4096 Sep 13 08:01 ../ -rw------- 1 robert users 6091 Sep 13 08:32 1158157923.13449_0.thunder.logicalchaos.org
Hmmm... I see the problem, but what is to be done about it?
I'm not using dnotify. I tried dnotify briefly, and the problem didn't appear to get any better, so I recompiled without - using poll now.
More thoughts?
Thanks, Rob
Robert Creager writes:
Do the timestamps of the directories change, when you get new mail? Did you searched the mail archive for inotify/dnotify problems?
No, they don't change: From dspam Wed Sep 13 08:32:03 2006 Subject: Re: [GENERAL] Template1 oops Folder: .PostgreSQL.General/new/1158157923.13449_0.thunder.logicalch 6091
[robert@thunder Maildir]$ ll -d .PostgreSQL.General/new drwx------ 2 robert users 8 Sep 13 07:57 .PostgreSQL.General/new/
ll -a .PostgreSQL.General/new/ total 16 drwx------ 2 robert users 8 Sep 13 07:57 ./ drwx------ 5 robert users 4096 Sep 13 08:01 ../ -rw------- 1 robert users 6091 Sep 13 08:32 1158157923.13449_0.thunder.logicalchaos.org
Hmmm... I see the problem, but what is to be done about it?
This is the reason why you're not getting notifications. Dovecot checks the timestamp of the directory to see if it has changed. That is how it detects if there is new mail. Normally, when a new message is inserted into a directory, the directory's timestamp should be updated. In your case, something strange is going on. I missed your earlier message, so I'm not sure if you described what kind of filesystem you have. Could you supply details of your filesystem (type and mount options)?
I'm not using dnotify. I tried dnotify briefly, and the problem didn't appear to get any better, so I recompiled without - using poll now.
I don't know the details of dnotify or poll, but if they also depend on metadata updates to detect a change, then they will also fail to work on your system. I think that if you solve the problem of the directory timestamp update, then you'll be alright.
-- Anand
Anand Buddhdev wrote:
[...]
I don't know the details of dnotify or poll, but if they also depend on metadata updates to detect a change, then they will also fail to work on your system. I think that if you solve the problem of the directory timestamp update, then you'll be alright.
Is it possible that it is being mounted with the 'noatime' flag?
-- Gerard Seibert gerard@seibercom.net
On Wednesday 13 September 2006 23:29, Dovecot Mailing List wrote:
Anand Buddhdev wrote:
[...]
I don't know the details of dnotify or poll, but if they also depend on metadata updates to detect a change, then they will also fail to work on your system. I think that if you solve the problem of the directory timestamp update, then you'll be alright.
Is it possible that it is being mounted with the 'noatime' flag?
No. The 'noatime' option to mount tells the kernel not to update the access time of files (ie. the time that a file is accessed in any way, such as read). However, delivery of a new message into a Maildir involves the update of the metadata of the directory that the file is written into, so the directory's mtime (modification time) is updated. This will happen regardless of the 'noatime' mount option.
You can test this for yourself by mounting a file system with 'noatime', and then creating a directory called 'test', looking at its mtime by running 'ls -l test', waiting a minute, creating a file in it by running 'touch test/file' and examining the mtime again by running 'ls -l'.
-- Anand
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 13 Sep 2006, Anand Buddhdev wrote:
No. The 'noatime' option to mount tells the kernel not to update the access time of files (ie. the time that a file is accessed in any way,
That's the idea of noatime, but would you hold your breath that it works like so in every circumstance, e.g. mount it noatime, export via NFS, re-export via NFS a second time, put a UNIONFS over it, etc. pp. So it is worth a try to drop all funny stuff for a test IMHO.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iQEVAwUBRQjxyC9SORjhbDpvAQJmPwf/TxK4ZTJAOgMAhPC5aHuHf+1EjXnPHzhK 7W0B2YNYewyBQdDrYnhl0zp/ZMompoPotzfDkQnk/p0om6d8SpDdfcpBBncPcBaC 22ebLKMFdg57CNkHTa8OG+72NujvobxR49wZu+EPFXe17sJmz2QB+x2J4mKVZYhY lQiRJoFBwrvBbnWwz3yB71V5nX080sQoJQkf5bp7gdHYaTWHB0otxuR0myCTBRfi HzUGzjRQK2dodxQxNkGIJPL+sraYJfqvIWmiMj0I911oaSjzG1nZkh8IgWYZrRtF WvJ1ITFHNtsP2wpiF24XuAyobX73rogtAjQpClYDe/hcIld1bU+oGw== =+bNJ -----END PGP SIGNATURE-----
Anand Buddhdev wrote:
Robert Creager writes:
Do the timestamps of the directories change, when you get new mail? Did you searched the mail archive for inotify/dnotify problems?
No, they don't change: I'm not sure if you described what kind of filesystem you have. Could you supply details of your filesystem (type and mount options)?
/dev/sda6 / jfs defaults 1 1
I had thought about the noatime mount option as I left this morning, as I use that on by db mount point, but not on the root file system.
your system. I think that if you solve the problem of the directory timestamp update, then you'll be alright.
Yeah, unless someone has some ideas on this, I'll have to hit another forum ;-)
Cheers, Rob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 13 Sep 2006, Robert Creager wrote:
/dev/sda6 / jfs defaults 1 1
I never used JFS, did you tested that the directory's timestamp change, when you create a new file in it? E.g. using 'echo > file'. I ask, because in the past long ago I ran into such issue with several filesystems, including ext2.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux)
iQEVAwUBRQjzVS9SORjhbDpvAQLZxQgAlAnUXGCdubXAYv0Xv3nBD/EL09coSALK 37fKyoYXMnJlZ35eo127aAODsARFNX73GYWxRPeYYnbcHpJ34fR9aiKGPS6y7D2X 7gGwNfiiFex9F97nB6k61Q7UdSCUbcga4eVfeOy51/LL+sJlavNRV1vKJIKj7GuF h0wKOPpYhtf5QlUEHWxMXbBGJEAJA3TJgoaalp+v5UZnvmZdp5Cnfi7aVhuM1ONf bAxE1TQPvly3FxR1UArIr4pzEQRrYVH/nUN/M4qDzd5od6rTiMcOwaV8Yz+UL6HD WxP0ZO0CT1RbQCp+V3hHRt/b8vva+0j625F7Fr4rOyIf06sL2Nw7Yw== =57NL -----END PGP SIGNATURE-----
Steffen Kaiser wrote:
On Wed, 13 Sep 2006, Robert Creager wrote:
/dev/sda6 / jfs defaults 1 1
I never used JFS, did you tested that the directory's timestamp change, when you create a new file in it? E.g. using 'echo > file'. I ask, because in the past long ago I ran into such issue with several filesystems, including ext2.
All right, I tried dnotify manually, and despite the times on directories not changing, I get notification (command line) when new mail arrives.
So I recompiled dovecot to use dnotify (--with-notify=dnotify), but it's still not working as it should. I have three mails in new, my command line dnotify saw all of them, but dovecot has not notified my client of them, or moved them out of new...
[robert@thunder ~]$ date Sat Sep 16 12:14:42 MDT 2006 [robert@thunder ~]$ ll Maildir/new/ total 24 -rw------- 1 robert users 6008 Sep 16 12:06 1158429973.15636_0.thunder.logicalchaos.org -rw------- 1 robert users 5713 Sep 16 12:06 1158429985.15694_0.thunder.logicalchaos.org -rw------- 1 robert users 5096 Sep 16 12:13 1158430398.22716_0.thunder.logicalchaos.org
How does doevcot use dnotify?
Cheers, Rob
Robert Creager wrote:
/dev/sda6 / jfs defaults 1 1
Check the list archives. There have been problems identified in the past with JFS, though I don't recall specifics.
Sorry I can't be more specific, but JFS does ring an alarm bell.
-- Curtis Maloney cmaloney@cardgate.net
Curtis Maloney wrote:
Robert Creager wrote:
/dev/sda6 / jfs defaults 1 1
Check the list archives. There have been problems identified in the past with JFS, though I don't recall specifics.
Sorry I can't be more specific, but JFS does ring an alarm bell.
That was specific enough for a few hits in the archives, but, it appears to be a non-problem these days. I'll check my kernel sources this weekend to see if I have the patches, but I suspect I should.
On this file system, when I touch a file in the directory, the directory time is updated. When I move a file into the directory, the time is updated. Anyone know how procmail does it? I guess I'll have to write some code and play around...
Cheers, Rob
Robert Creager wrote:
On this file system, when I touch a file in the directory, the directory time is updated. When I move a file into the directory, the time is updated. Anyone know how procmail does it? I guess I'll have to write some code and play around...
Is it a "move with hardlinks" issue? I have some vague recollection of needing that, though I'm using 0.99.14 and haven't had to solve problems since before it was released...
-- Curtis Maloney cmaloney@cardgate.net
On Thu, 2006-09-14 at 08:05 -0600, Robert Creager wrote:
Curtis Maloney wrote:
Robert Creager wrote:
/dev/sda6 / jfs defaults 1 1
Check the list archives. There have been problems identified in the past with JFS, though I don't recall specifics.
Sorry I can't be more specific, but JFS does ring an alarm bell.
That was specific enough for a few hits in the archives, but, it appears to be a non-problem these days. I'll check my kernel sources this weekend to see if I have the patches, but I suspect I should.
On this file system, when I touch a file in the directory, the directory time is updated. When I move a file into the directory, the time is updated. Anyone know how procmail does it? I guess I'll have to write some code and play around...
The problem is that hardlinking a file to another directory didn't update the directory's mtime. You most likely don't have that bug fixed in your kernel.
Timo Sirainen wrote:
The problem is that hardlinking a file to another directory didn't update the directory's mtime. You most likely don't have that bug fixed in your kernel.
Interesting. Where are the files hard linked from? They show up in the new directory, but where else are they?
Thanks, Rob
On Fri, 2006-09-22 at 08:43 -0600, Robert Creager wrote:
Timo Sirainen wrote:
The problem is that hardlinking a file to another directory didn't update the directory's mtime. You most likely don't have that bug fixed in your kernel.
Interesting. Where are the files hard linked from? They show up in the new directory, but where else are they?
The way maildir delivery works is:
create the file in tmp/ hardlink it to new/ unlink from tmp/
The last two steps could be done with a rename() which would fix the JFS problem, but since there's a tiny (practically non-existent with Dovecot) possibility of that overwriting a mail file in new/ dir, link()+unlink() is done.
Timo Sirainen wrote:
The way maildir delivery works is:
create the file in tmp/ hardlink it to new/ unlink from tmp/
The last two steps could be done with a rename() which would fix the JFS problem, but since there's a tiny (practically non-existent with Dovecot) possibility of that overwriting a mail file in new/ dir, link()+unlink() is done.
Alright. Would using Dovecot's LDA (using procmail now) solve the problem a slightly different way? Or is the LDA just good for updating the index files?
Thanks, Rob
On Fri, 2006-09-22 at 11:05 -0600, Robert Creager wrote:
Timo Sirainen wrote:
The way maildir delivery works is:
create the file in tmp/ hardlink it to new/ unlink from tmp/
The last two steps could be done with a rename() which would fix the JFS problem, but since there's a tiny (practically non-existent with Dovecot) possibility of that overwriting a mail file in new/ dir, link()+unlink() is done.
Alright. Would using Dovecot's LDA (using procmail now) solve the problem a slightly different way? Or is the LDA just good for updating the index files?
No. Everything that writes to maildir uses the link() + unlink() method. Although if you did use Dovecot LDA, you could change the link()+unlink() to rename() call only in Dovecot's sources.. I'd still just suggest upgrading the kernel. :)
Timo Sirainen wrote:
No. Everything that writes to maildir uses the link() + unlink() method. Although if you did use Dovecot LDA, you could change the link()+unlink() to rename() call only in Dovecot's sources.. I'd still just suggest upgrading the kernel. :)
Alright. Now running 2.6.18 kernel, and I'm getting instant notification, but only for Inbox. Not for any other folders (using procmail filtering). I have subscribed (Thunderbird client) to every folder, and if I manually go to the folder, I get notification of the new messages, but not until then.
Am I missing something else?
The stuff I've changed in the config file (from 1.0.rc7):
[robert@thunder Maildir]$ egrep -v '^ *(#|$)' /etc/dovecot/dovecot.conf base_dir = /var/lib/dovecot/ protocols = imaps ssl_cert_file = /etc/ssl/dovecot/certs/dovecot.pem ssl_key_file = /etc/ssl/dovecot/private/dovecot.pem default_mail_env = maildir:%h/Maildir verbose_proctitle = yes protocol imap { imap_client_workarounds = tb-extra-mailbox-sep } auth default { mechanisms = plain passdb pam { } userdb passwd { } user = root }
Thanks, Rob
Robert Creager wrote:
Hi Robert,
Alright. Now running 2.6.18 kernel, and I'm getting instant notification, but only for Inbox. Not for any other folders (using procmail filtering). I have subscribed (Thunderbird client) to every folder, and if I manually go to the folder, I get notification of the new messages, but not until then.
Am I missing something else?
Instant notifications are made possible by the IMAP IDLE command. Your mail client (Thunderbird), selects a folder, and then sends the IDLE commands to the server. The server then pauses; as soon as a message is delivered into that folder, it returns, and notifies the client of new mail.
Unfortunately, the IMAP IDLE extension only works with one mailbox at a time. This is a limitation in the protocol, and both Dovecot and Thunderbird are simply following the protocol. If I remember correctly, Thunderbird only uses IDLE for the INBOX. And while it is using IDLE, it cannot poll the other folders for new mail (well, I suppose it could come out of IDLE, poll all the folders, and go back to IDLE, but it seems like an ugly hack). So you can only use one of 2 modes: either use IDLE, and get notifications of new mail in INBOX only, or use normals periodic polls of all your folders to get notifications of new mail in all of them.
-- Anand
Unfortunately, the IMAP IDLE extension only works with one mailbox at a time. This is a limitation in the protocol, and both Dovecot and Thunderbird are simply following the protocol. If I remember correctly, Thunderbird only uses IDLE for the INBOX. And while it is using IDLE, it cannot poll the other folders for new mail (well, I suppose it could come out of IDLE, poll all the folders, and go back to IDLE, but it seems like an ugly hack). So you can only use one of 2 modes: either use IDLE, and get notifications of new mail in INBOX only, or use normals periodic polls of all your folders to get notifications of new mail in all of them.
I may be mistaken, but doesn't 'ENHANCED_IDLE' work with not only multiple/concurrent connections to the same folder, but also multiple folders?
--
Best regards,
Charles
Charles Marcus wrote:
Unfortunately, the IMAP IDLE extension only works with one mailbox at a time. This is a limitation in the protocol, and both Dovecot and Thunderbird are simply following the protocol. If I remember correctly, Thunderbird only uses IDLE for the INBOX. And while it is using IDLE, it cannot poll the other folders for new mail (well, I suppose it could come out of IDLE, poll all the folders, and go back to IDLE, but it seems like an ugly hack). So you can only use one of 2 modes: either use IDLE, and get notifications of new mail in INBOX only, or use normals periodic polls of all your folders to get notifications of new mail in all of them.
I may be mistaken, but doesn't 'ENHANCED_IDLE' work with not only multiple/concurrent connections to the same folder, but also multiple folders?
As far as I know, ENHANCED_IDLE works only with one folder at a time. It is similar to IDLE, but allows all clients that have the same folder open, to receive notifications of changes to that folder at the same time. I think that at the moment, only Courier-IMAP supports it.
In my experience, the only way to get notified of new mail in more than one folder is poll all the folders regularly. It is ugly, and the more folders you have the more traffic it generates. Thunderbird makes it worse by initially selecting each folder (and subfolders) for a poll. Even a modest numbers of mailboxes will cause a lot of polling, especially if you check for mail every minute. One has to manually go and turn off the poll for all the folders where notification is not needed.
The person who designed the IDLE extension was obviously not thinking properly. What's the point in having a multi-folder mail access protocol such as IMAP if the server can't notify the client of changes in the folders? However, the protocol's designer is rather pig-headed, and firmly refuses to entertain the idea of IDLE for multiple folders.
-- Anand
On 25.9.2006, at 16.40, Anand Buddhdev wrote:
The person who designed the IDLE extension was obviously not thinking properly. What's the point in having a multi-folder mail access protocol such as IMAP if the server can't notify the client of changes in the folders? However, the protocol's designer is rather pig-headed, and firmly refuses to entertain the idea of IDLE for multiple folders.
Well, it's really not simple from the protocol point of view and it
wouldn't be simple to implement either. The protocol supports only a
single mailbox to be selected at a time, and changing that would be a
huge change.
However the existing protocol pretty much already makes it possible:
Whenever a mailbox changes, send a STATUS reply to client containing
the changes (messages/unread/etc. counters). This is what the clients
want to know anyway. I don't know if any clients actually support
this, probably not. No servers support this either, although I was
thinking about adding support for it once my mailbox list index is
working.
However the existing protocol pretty much already makes it possible: Whenever a mailbox changes, send a STATUS reply to client containing the changes (messages/unread/etc. counters). This is what the clients want to know anyway. I don't know if any clients actually support this, probably not. No servers support this either, although I was thinking about adding support for it once my mailbox list index is working.
Interesting - Dovecot would then be even *further* out on the cutting edge... :)
When you say 'the existing protocol', do you mean the IDLE/ENHANCED_IDLE' protocol?
I think it would be great for Dovecot to support this - then it would simply (sic) be a matter of getting the mail clients (Thunderbird, etc) to support it...
Any idea how much work *that* might be? Obviously, the simpler, the more chance of getting the devs to implement it.
--
Best regards,
Charles
On Mon, 2006-09-25 at 14:39 -0400, Charles Marcus wrote:
However the existing protocol pretty much already makes it possible: Whenever a mailbox changes, send a STATUS reply to client containing the changes (messages/unread/etc. counters). This is what the clients want to know anyway. I don't know if any clients actually support this, probably not. No servers support this either, although I was thinking about adding support for it once my mailbox list index is working.
Interesting - Dovecot would then be even *further* out on the cutting edge... :)
When you say 'the existing protocol', do you mean the IDLE/ENHANCED_IDLE' protocol?
I've no idea what ENHANCED_IDLE is. Some Thunderbird-specific name for something? In any case there's no such protocol.
And yea, I mean the existing IMAP RFC which already sends STATUS replies when asked with STATUS command. They could be sent to client when it's IDLEing (and could be sent even when it's not).
I think it would be great for Dovecot to support this - then it would simply (sic) be a matter of getting the mail clients (Thunderbird, etc) to support it...
Any idea how much work *that* might be? Obviously, the simpler, the more chance of getting the devs to implement it.
The good thing with the STATUS-reply way is that the clients already are parsing them. Most clients however seem to ignore all the untagged events that they didn't themself request from the server.
hmmmm. maybe enhanced idle is what hybrid cars have? Thanks for all you've done, and don't let the foolishness get you down. I am about to shift from UW-IMAP....had a user called me up and very sullenly and self-righteously telling me that 90 messages in his INBOX had 'deleted themselves'. I had a hard time not breaking down into hysterical laughter........
Timo Sirainen wrote:
On Mon, 2006-09-25 at 14:39 -0400, Charles Marcus wrote:
However the existing protocol pretty much already makes it possible: Whenever a mailbox changes, send a STATUS reply to client containing the changes (messages/unread/etc. counters). This is what the clients want to know anyway. I don't know if any clients actually support this, probably not. No servers support this either, although I was thinking about adding support for it once my mailbox list index is working.
Interesting - Dovecot would then be even *further* out on the cutting edge... :)
When you say 'the existing protocol', do you mean the IDLE/ENHANCED_IDLE' protocol?
I've no idea what ENHANCED_IDLE is. Some Thunderbird-specific name for something? In any case there's no such protocol.
And yea, I mean the existing IMAP RFC which already sends STATUS replies when asked with STATUS command. They could be sent to client when it's IDLEing (and could be sent even when it's not).
I think it would be great for Dovecot to support this - then it would simply (sic) be a matter of getting the mail clients (Thunderbird, etc) to support it...
Any idea how much work *that* might be? Obviously, the simpler, the more chance of getting the devs to implement it.
The good thing with the STATUS-reply way is that the clients already are parsing them. Most clients however seem to ignore all the untagged events that they didn't themself request from the server.
--
Stewart Dean, Unix System Admin, Henderson Computer Resources
Center of Bard College, Annandale-on-Hudson, New York 12504
sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035
When you say 'the existing protocol', do you mean the IDLE/ENHANCED_IDLE' protocol?
I've no idea what ENHANCED_IDLE is. Some Thunderbird-specific name for something? In any case there's no such protocol.
Hmmm... googling, I see lots of references - but nothing concrete. Seems it may be some kind of extension to the IDLE protocol... Courier supports it - and in fact, almost every google hit is courier related.
And yea, I mean the existing IMAP RFC which already sends STATUS replies when asked with STATUS command. They could be sent to client when it's IDLEing (and could be sent even when it's not).
I think it would be great for Dovecot to support this - then it would simply (sic) be a matter of getting the mail clients (Thunderbird, etc) to support it...
Any idea how much work *that* might be? Obviously, the simpler, the more chance of getting the devs to implement it.
The good thing with the STATUS-reply way is that the clients already are parsing them. Most clients however seem to ignore all the untagged events that they didn't themself request from the server.
Cool - means it may be trivial to get the Client to just not ignore them...
--
Best regards,
Charles
Charles Marcus wrote:
I've no idea what ENHANCED_IDLE is. Some Thunderbird-specific name for something? In any case there's no such protocol.
Hmmm... googling, I see lots of references - but nothing concrete. Seems it may be some kind of extension to the IDLE protocol... Courier supports it - and in fact, almost every google hit is courier related.
You're right. See my earlier posting. ENHANCED_IDLE is specific to courier, but it's not an extension to the IMAP protocol. It's just courier's way of implementing it, such that it works with the IDLE command, but allows some extra functionality.
The good thing with the STATUS-reply way is that the clients already are parsing them. Most clients however seem to ignore all the untagged events that they didn't themself request from the server.
Cool - means it may be trivial to get the Client to just not ignore them...
Yes, it would be cool to get clients to actually do something with the unsolicited status replies that IMAP servers send them. IMAP servers can send a lot of useful information with these replies. With the exception of a very small minority, most IMAP clients ignore these status updates, and that's a shame.
-- Anand
Timo Sirainen wrote:
When you say 'the existing protocol', do you mean the IDLE/ENHANCED_IDLE' protocol?
I've no idea what ENHANCED_IDLE is. Some Thunderbird-specific name for something? In any case there's no such protocol.
ENHANCED_IDLE is not an extension to IDLE. It's a courier-specific enhancement to the IDLE command, and it allows several connected clients to receive information about updates to a selected mailbox. Clients don't need to do anything special. They just send the IDLE command as usual, and as soon as there is a change to the folder, all the clients that have selected that folder receive an update.
Anand Buddhdev wrote:
Charles Marcus wrote:
In my experience, the only way to get notified of new mail in more than one folder is poll all the folders regularly. It is ugly, and the more folders you have the more traffic it generates. Thunderbird makes it worse by initially selecting each folder (and subfolders) for a poll. Even a modest numbers of mailboxes will cause a lot of polling, especially if you check for mail every minute. One has to manually go and turn off the poll for all the folders where notification is not needed.
The person who designed the IDLE extension was obviously not thinking properly. What's the point in having a multi-folder mail access protocol such as IMAP if the server can't notify the client of changes in the folders? However, the protocol's designer is rather pig-headed, and firmly refuses to entertain the idea of IDLE for multiple folders.
Thanks for all the info (and the following replies). It's interesting that a service that is server based (message storage), appears to want client side filtering of those messages.
I thought I was moving up from POP3 so I could get my e-mail from any old client, as I had all my filtering client based previously. So I moved it to server based (via procmail), but cannot get notification now. Not Dovecot's problem, just my pre-concieved notions being soundly squished.
I love Dovecot. It's been the easiest piece of software I've never had to configure to get working ;-)
Cheers, Rob
participants (9)
-
Anand Buddhdev
-
Charles Bueche
-
Charles Marcus
-
Curtis Maloney
-
Dovecot Mailing List
-
Robert Creager
-
Steffen Kaiser
-
Stewart Dean
-
Timo Sirainen