HIGHESTMODSEQ tracking

[Kostya Vasilyev]

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