On 10.4.2012, at 23.50, Glenn Wurster wrote:
>> Yes, modseqs aren't tracked in a mailbox until client expresses an
>> interest for them. It would be a waste of disk space to save them
>> since 99% of users don't need them.
>
> Makes sense, our mail client gets caught in the middle though, because it
> uses HIGHESTMODSEQ to track mailbox updates without using MODSEQ options on
> SELECT/FETCH to track message updates.
It would be actually possible for Dovecot to always keep track of
highestmodseq, even if individual modseqs weren't tracked. I almost implemented
it, but keeping it backwards compatible with old versions would have needed to
make it more complex. Maybe v2.2 could do this.
>> 2) If a mailbox doesn't have modseqs enabled, return NOMODSEQ. This
>> isn't ideal, but seems like the only possibility.
>
> The RFC also states that if we return NOMODSEQ we'd have to return a tagged
> BAD response to "UID FETCH 1 MODSEQ", which appears to one of the commands
> that enables MODSEQ for Dovecot ("SELECT INBOX (CONDSTORE)" also enables
> it...). What about returning a BAD response and at the same time start
> tracking MODSEQ so that future SELECT commands would return HIGHESTMODSEQ?
> Do we know what email clients are using CONDSTORE options and how they'd
> react to a mailbox suddenly having MODSEQ capabilities after we just told
> them it didn't?
That's kind of an annoying part of the RFC that it says the commands MUST fail
with BAD.. I don't think there was really any good reason to add that text.
Also Dovecot hasn't failed those commands earlier also with mailbox formats
that don't support modseqs at all. So at least for now I simply made it return
NOMODSEQ when modseqs aren't enabled, and the rest of the behavior is the same.
