HIGHESTMODSEQ tracking

[Michael M Slusarz]

Quoting Kostya Vasilyev <kmansoft at gmail.com>:

> 2014-07-10 1:37 GMT+04:00 Michael M Slusarz <slusarz at curecanti.org>:
>
> Quoting Kostya Vasilyev <kmansoft at gmail.com>:
>>
>> 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 :)

This is the wrong way to look at it though.

You should implement QRESYNC initially, because it will force you to  
implement CONDSTORE also.

It's going to be 10x harder to implement CONDSTORE and then add  
QRESYNC functionality on top of it later.  Do it right the first time.

Both Dovecot and Cyrus support both CONDSTORE and QRESYNC, and  
combined that is more than 50% market share, so that should be  
incentive enough.  Gmail only supports CONDSTORE, but it's the outlier.

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

Maybe.  You can't tell until you actually see whether the  
EXAMINE/SELECT returns HIGHESTMODSEQ or NOMODSEQ.

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

AFAICT, the mailing list message you are referring to is talking about  
what Dovecot returns **when CONDSTORE is not enabled**.  As I  
mentioned before, this should be irrelevant to your client since you  
shouldn't be using HIGHESTMODSEQ if you haven't enabled CONDSTORE.

Older versions of Dovecot happen to send CONDSTORE info even if it's  
not active (which is perfectly valid IMAP behavior).  *This* was the  
issue referred to in that message ... some clients didn't enable  
CONDSTORE but were using HIGHESTMODSEQ if it existed to use it as a  
"Uniqu eID" (combined with the current UIDVALIDITY) of the mailbox for  
polling purposes.  It was these clients that were seeing broken  
behavior since this "Unique ID" never changed - since UIDVALIDITY  
normally won't ever change - since HIGHESTMODSEQ would always be 1.   
These clients should have never been doing that in the first place,  
but whatever.

Once you issue a CONDSTORE-enabling command, this is no longer an  
issue.  So it's not something a client ever has to workaround as long  
as they are following the RFC.

michael