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