RFC 5465 (NOTIFY) violation: missing HIGHESTMODSEQ in initial STATUS responses
Guilhem Moulin
guilhem at fripost.org
Sun Jul 19 17:40:14 UTC 2015
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>
More information about the dovecot
mailing list