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