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 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