[Dovecot] Bug in HIGHESTMODSEQ when MODSEQ tracking is not enabled for version 2.0.18.

[Timo Sirainen]

On 10.4.2012, at 20.17, Glenn Wurster wrote:

> It appears as if HIGHESTMODSEQ is not being updated.  I can get HIGHESTMODSEQ to start updating correctly if I send a "UID FETCH 1 MODSEQ" or similar command, which appears to enable MODSEQ tracking at the server (according to the comment around line 173 in file src/lib-index/mail-index-modseq.c), but until that command is sent, MODSEQ tracking is not enabled and hence HIGHESTMODSEQ is always going to return 1.

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.

> According to RFC4551, the combination of HIGHESTMODSEQ and UIDVALIDITY should be sufficient to determine if the metadata associated with the mailbox has changed, but in this case looking at only those two parameters does not yield sufficient information about changes in the mailbox.  The mail client I'm using relies on the combination of HIGHESTMODSEQ and UIDVALIDITY to determine if there are changes in the mailbox, and hence does not see new mail come in.

Yeah, it does seem that the RFC says that..

> It seems that Dovecot should not be returning HIGHESTMODSEQ in response to a command if MODSEQ tracking is not enabled, but I could be wrong.  I've attached my configuration (it's Dovecot 2.0.18 running on Debian Stable).

RFC 4551 says that HIGHESTMODSEQ or NOMODSEQ MUST be returned. Hmm. Perhaps:

1) If the session is known to have modseqs enabled, immediately enable modseqs for newly created mailboxes

2) If a mailbox doesn't have modseqs enabled, return NOMODSEQ. This isn't ideal, but seems like the only possibility.