HIGHESTMODSEQ tracking

[Kostya Vasilyev]

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

> 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 :)
>>
>
> [ 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