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.
- 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.