HIGHESTMODSEQ tracking

[Michael M Slusarz]

Quoting Kostya Vasilyev <kmansoft at 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