Oh, and this was also fixed a week ago: http://hg.dovecot.org/dovecot-2.2/rev/238a34ad1ab0
On 07/19/2015 08:40 PM, Guilhem Moulin wrote: > Quoting RFC 5465 (NOTIFY): > > “If the NOTIFY command enables MessageNew, MessageExpunge, > AnnotationChange, or FlagChange notifications for a mailbox other > than the currently selected mailbox, and the client has specified > the STATUS indicator parameter, then the server MUST send a STATUS > response for that mailbox before NOTIFY's tagged OK. […] > If either AnnotationChange or FlagChange are included and > the server also supports the CONDSTORE [RFC4551] and/or QRESYNC > [RFC5162] extensions, the STATUS response MUST contain UIDVALIDITY > and HIGHESTMODSEQ.” — > https://tools.ietf.org/html/rfc5465#section-3.1 > > While unsolicited STATUS responses include HIGHESTMODSEQ indeed, the initial > STATUS responses (caused by the presence of the STATUS indicator) do not: > > ~$ /usr/lib/dovecot/imap > * PREAUTH [CAPABILITY IMAP4rev1 … CONDSTORE QRESYNC … NOTIFY SPECIAL-USE] > Logged in as guilhem > a ENABLE QRESYNC > * ENABLED QRESYNC > a OK Enabled (0.000 secs). > b NOTIFY SET STATUS (SUBSCRIBED (MessageNew MessageExpunge FlagChange)) > * STATUS INBOX (MESSAGES 9069 UIDNEXT 109398 UIDVALIDITY 1312585007 > UNSEEN 0) > […] > b OK NOTIFY completed (0.008 secs). > [time passes… a new message is delivered to INBOX] > * STATUS INBOX (MESSAGES 9070 UIDNEXT 109399 UNSEEN 1 HIGHESTMODSEQ 22216) > > This defeats the purpose of the STATUS indicator for disconnected > clients since they have to issue separate STATUS commands (or a LIST > command if LIST-{EXTENDED,STATUS} have been advertized) to find out > which mailboxes have got a new HIGHESTMODSEQ. > > Cheers, >
