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.
