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