2014-07-10 4:05 GMT+04:00 Michael M Slusarz <slusarz@curecanti.org>:
Quoting Kostya Vasilyev <kmansoft@gmail.com>:
2014-07-10 1:37 GMT+04:00 Michael M Slusarz <slusarz@curecanti.org>:
Quoting Kostya Vasilyev <kmansoft@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 :)
[ snip ] 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.
Gmail still does have a few users, though. A few dozen at least, maybe more :)
And it has a big advantage, from my point of view, over Cyrus / Dovecot -- there is but one server version that's consistent for all accounts.
Yes, they do some things wrong (like not sending message flags changes over IDLE connections), but I can test something in my personal account, get feedback from 3-5-10 users with @gmail accounts, and be reasonably confident that everything is fine (and that I'd know know if it's not).
Now, Cyrus and Dovecot (and Courier I guess) is a different story, there is a variety of versions out there, and software being software, there may be bugs / glitches / quirks.
Since you mention Cyrus, do you know that it often (like, almost always) responds to "ID" with a "NO"? This is not RFC compliant, but it's what is actually does.
For the "more than 50% market share" of Dovecot / Cyrus, do you have a breakdown by version number? At least in terms of 1.* vs 2.0 and higher?
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.
Are you saying that Dovecot will always (*will always*, and I mean *always*) return NOMODSEQ after a client "expresses interested in modseq values" and the server can't enable it for some reason?
Or if it was previously enabled, and then well, I don't know, "something happened"?
By *always* I mean -- since Dovecot first started having a CONDSTORE in its CAPS, including version a.b.c that came with now really old Debian X, and version h.j.k that came with now really old RHEL Y, but which are still out there on actual mail servers, being used in actual mail accounts?
When something goes wrong in an email app, then to the user, it's always the email app developer's fault. Nobody gives a damn about the subtleties of what RFC abc says about xyz, or if server version j.k.l from three years ago had a bug.
So, before enabling certain optimizations for Dovecot, I thought I'd ask on a Dovecot mailing list, about actual behavior for this server feature.
I assume this mailing list has people with real Dovecot experience and knowledge, and maybe even the developers are lurking here too.
Specifically, I was hoping to hear back maybe something like this:
"Dovecot version X which was packaged in Debian Z, would not update the modseq value after command Y".
Or maybe -- which would be great:
"There were no issues with modseq tracking, at all, no reported bugs, code not touched, since the feature was originally implemented and advertised as CONDSTORE in CAPS in version 1.2.*".
-- K