Fwd: HIGHESTMODSEQ tracking

[Kostya Vasilyev]

Michael,


2014-07-10 1:37 GMT+04:00 Michael M Slusarz <slusarz at curecanti.org>:

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.


True, but I was just pointing out a quirk that existed in a older version,
to ask for a clarification.


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

Thanks, didn't notice that 4551 was "obsoleted".


>
> Also note there's actually 6 different categories of CONDSTORE-enabling
> commands. SELECT/EXAMINE with CONDSTORE is just one of the categories.
>

There are five listed in RFC 4551, yes, there are six in 7162, but my
question was about two specific ones out of those five / six.


>
> These days, you *really* should be using QRESYNC instead though.


There are some mail servers that support CONDSTORE but not QRESYNC. The old
chicken and egg IMAP problem :)


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


Incorrect?

I wrote: "it seems that Dovecot 2.1.7 enables persistent modseq
tracking...".

Are you implying that Dovecot 2.1.7 doesn't enable persistent modseq
tracking in this case?

I never claimed that earlier versions of Dovecot didn't advertise CONDSTORE
or didn't implement it properly, etc.

Perhaps I should have written "...after *any* of the two commands... (and
maybe others)" -- meaning it does after either of those two commands, and
the other ones I don't care about and so didn't test.


>  And as mentioned above, there are 6 different ways of enabling CONDSTORE.
>  (Enabling QRESYNC is done 1 way ... the "ENABLE QRESYNC" command).


Yes, agreed, noted.

I'm asking about two out of those five / six.

And not just about what the RFC says, but about how real, out in the field,
installed on mail servers that people use, possibly quite old, versions of
Dovecot behave.

So let me try again:

Is sending SELECT ... (CONDSTORE) or STATUS (... HIGHESTMODSEQ ...) enough
to enable reliable persistent modseq tracking for all versions of Dovecot
which advertise CONDSTORE in their capabilities?

Not what the currently relevant RFC says, but how Dovecot versions with
CONDSTORE in their caps behave.

This is the one thing I'd really like to know.


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


All caps look nice in RFCs, but the real world has more variety :)


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


Agreed. However:


>  Returning NOMODSEQ on mailboxes that don't support persistent
> mod-sequences has worked since 1.2.0, at least as far as I know.


The linked message from 2012, discussing 2.0.18, says:

"2) If a mailbox doesn't have modseqs enabled, return NOMODSEQ. This isn't
ideal, but seems like the only possibility"

And based on my tests, Dovecot 2.1.7 returns "HIGHESTMODSEQ 1" for
mailboxes where modseq tracking has not been enabled.

You're largely right about the value only being relevant if the client
enabled CONDSTORE, and I don't care too much about this quirk, just wanted
to to get a clarification on this as well, if possible.

Thanks,
-- K