HIGHESTMODSEQ tracking
Hello,
I'd like to follow up on someone else's old thread:
http://dovecot.org/list/dovecot/2012-April/082624.html
I understand that Dovecot (that 2012 discussion was about version 2.0.18) can return "HIGHESTMODSEQ 1" upon SELECT if persistent modseq tracking was never enabled for a mailbox.
I'd like to get a clarification on how to enable proper persistent modseq tracking.
Per RFC 4551, "A client supporting CONDSTORE.... indicates its willingness to receive mod-sequence updates... by issuing:"
SELECT mailbox (CONDSTORE) STATUS (... HIGHESTMODSEQ ...) ... others ...
It seems that Dovecot 2.1.7 (Debian 7.5) enables persistent modseq tracking after one of the above two commands (and maybe others). So far so good.
So my questions are:
1 - Is this (enabling persistent modseq) also the case for all Dovecot versions prior to 2.1.7 that advertise CONDSTORE?
There must be people running older versions out there, older than 2.1.7.
If not, how can I branch my logic to not use HIGHESTMODSEQ, given that Dovecot doesn't appear to return any version info via its greeting or via the ID command?
2 - Is persistent modseq tracking (assuming it's been enabled) available for all types of backend mailbox formats that Dovecot might be using?
To be more specific, can it ever be the case that Dovecot appears to enable modseq tracking, returning nice looking HIGHESTMODSEQ values from SELECT / STATUS, but the actual values get reset or not get updated because they're not properly persistent?
I'm excluding changes to UIDVALIDITY here, obviously when that changes, the entire mailbox state must be assumed to have changed completely.
3 - I guess the change to return NOMOSEQ instead of "1" for mailboxes with modseq tracking disabled, as mentioned in that discussion from 2012, never happened? At least on the 2.1 branch?
Thanks, -- K
Quoting Kostya Vasilyev <kmansoft@gmail.com>:
Hello,
I'd like to follow up on someone else's old thread:
http://dovecot.org/list/dovecot/2012-April/082624.html
I understand that Dovecot (that 2012 discussion was about version 2.0.18) can return "HIGHESTMODSEQ 1" upon SELECT if persistent modseq tracking was never enabled for a mailbox.
This behavior is largely irrelevant ... a client should ignore any
HIGHESTMODSEQ data that is sent if it (the client) hasn't sent a
CONDSTORE enabling command.
I'd like to get a clarification on how to enable proper persistent modseq tracking.
Per RFC 4551, "A client supporting CONDSTORE.... indicates its willingness to receive mod-sequence updates... by issuing:"
SELECT mailbox (CONDSTORE) STATUS (... HIGHESTMODSEQ ...) ... others ...
4551 is deprecated --> it is now RFC 7162.
Also note there's actually 6 different categories of
CONDSTORE-enabling commands. SELECT/EXAMINE with CONDSTORE is just one
of the categories.
These days, you *really* should be using QRESYNC instead though.
It seems that Dovecot 2.1.7 (Debian 7.5) enables persistent modseq tracking after one of the above two commands (and maybe others). So far so good.
Incorrect. Dovecot has supported CONDSTORE/QRESYNC since 1.2.0. And
as mentioned above, there are 6 different ways of enabling CONDSTORE.
(Enabling QRESYNC is done 1 way ... the "ENABLE QRESYNC" command).
So my questions are:
1 - Is this (enabling persistent modseq) also the case for all Dovecot versions prior to 2.1.7 that advertise CONDSTORE?
There must be people running older versions out there, older than 2.1.7.
If not, how can I branch my logic to not use HIGHESTMODSEQ, given that Dovecot doesn't appear to return any version info via its greeting or via the ID command?
As noted above, this is irrelevant. As a client author, you should
ALWAYS ignore HIGHESTMODSEQ if you haven't enabled CONDSTORE/QRESYNC .
3 - I guess the change to return NOMOSEQ instead of "1" for mailboxes with modseq tracking disabled, as mentioned in that discussion from 2012, never happened? At least on the 2.1 branch?
NOMODSEQ is only relevant *if* you have enabled CONDSTORE. Returning
NOMODSEQ on mailboxes that don't support persistent mod-sequences has
worked since 1.2.0, at least as far as I know.
michael
participants (2)
-
Kostya Vasilyev
-
Michael M Slusarz