[Dovecot] Differences between IDLE when Maildir vs. wel the "mail" folder is used
tss at iki.fi
Mon Feb 12 17:55:17 UTC 2007
On Sat, 2007-02-10 at 12:58 +0100, Philip Van Hoof wrote:
> Dovecot's IDLE (the EXISTS) responses also take a lot longer on tnytest2
> than on tnytest.
That is because with maildir Dovecot can use kernel's dnotify support to
know immediately when a new mail arrives. Inotify apparently supports
also waiting for file changes, so I think it should work if you
configure --with-notify=inotify. I'll have to try this myself too..
> * OK [UIDNEXT 1] Predicted next UID
> a01 OK [READ-WRITE] Select completed.
> a04 IDLE
> + idling
> * 1 EXISTS
How did you get those messages into the mailbox? Just wondering why it's
not giving RECENT reply.
> a04 OK Idle completed.
> a05 UID FETCH 1:1 (FLAGS UID)
> a05 OK Fetch completed.
Looks like I can reproduce this. At least with empty mailboxes it seems
that Dovecot gives a new UID to a mail that already had it. I'll go and
However, Dovecot's behavior is perfectly valid from IMAP protocol's
point of view. You shouldn't be assuming that the new UID is the same as
UIDNEXT. For example another session could have just appended two
messages and expunged the first one. In that case you'll see exactly the
above behavior from all the IMAP servers.
So you really should be using message sequence numbers instead of UIDs
before you're completely certain what the UID is. And even still using
sequence numbers is a more "correct" IMAP way to do it, plus it's
slightly faster :) I think the UIDs are mostly useful only for some
initial local cache syncing when the mailbox is opened.
> a06 UID FETCH 1:4 (FLAGS UID)
> * 1 FETCH (FLAGS (\Seen) UID 2)
> * 2 FETCH (FLAGS (\Seen) UID 3)
> * 3 FETCH (FLAGS (\Seen) UID 4)
> a06 OK Fetch completed.
This is because the fourth message had UID 5 and you exluded it from the
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20070212/939f0896/attachment.pgp
More information about the dovecot