Guilhem Moulin
2015-Jul-19 17:40 UTC
RFC 5465 (NOTIFY) violation: missing HIGHESTMODSEQ in initial STATUS responses
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, -- Guilhem. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://dovecot.org/pipermail/dovecot/attachments/20150719/e497d171/attachment.sig>
Timo Sirainen
2015-Sep-07 21:37 UTC
RFC 5465 (NOTIFY) violation: missing HIGHESTMODSEQ in initial STATUS responses
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, >
Seemingly Similar Threads
- Crash: setannotation Trash "/vendor/cmu/cyrus-imapd/expire" ("value.shared" NIL)
- "NOTIFY SET (mailboxes INBOX (...))" crashes the IMAP client
- NOTIFY broken in 2.2.31?
- NOTIFY regression: 2.18 no longer notifies of events in INBOX
- Race condition in IMAP NOTIFY for events received NOTIFY_DELAY_MSECS apart