[Dovecot] automatic flag updates

[Aaron VanDevender]

On Tue, 2004-11-30 at 09:00 +0200, Timo Sirainen wrote:
> > at this point I expect client A to change the status of the mail in
> > question to SEEN, but it stays as UNSEEN. The session below is from
> > client A. Command A00069 reports [UNSEEN 16265]
> 
> That does seem to be bug.

Do you mean an Evolution bug, or a Dovecot bug?

> If Evolution had done NOOP command instead of SELECT, it would have 
> received the FETCH FLAGS response. I don't think the FETCH FLAGS should 
> be sent when mailbox is being changed (even if it's for the same 
> mailbox).

I think it should give FETCH FLAGS responses to a SELECT request, and I
think that RFC2060 agrees with me, although it's pretty ambiguous for
the non-NOOP case. But my interpretation of section 7 is that unilateral
FETCH FLAGS updates should come whenever a flag changes, no matter what
the client is doing. The reason is that even if you are giving periodic
NOOP requests, from time to time client A will still want to FETCH a
different folder or write something to a Sent mail folder or something,
and its possible that a flag could get updated on a message in the
interval after the last NOOP, but before the client can SELECT back to
the INBOX folder, meaning the client can still get out of sync, even if
it is sending NOOP requests constantly. The only way to protect against
that sort of race condition is to have the SELECT request return FETCH
updates.

This race window is even wider for other folders. If the client spends
most of its time in INBOX, and only periodically SELECTs over to, say, a
Mailing-List folder, for a STATUS or a LIST check, then most likely if a
message in the Mailing-List folder is marked SEEN it won't be picked up
by the client at all, because it was NOOPing INBOX and SELECT doesn't
return FETCH FLAGS. The only way to avoid this is just to have SELECT
return FETCH FLAGS updates.

> In any case, last I checked Evolution (v1.4.x) just ignored FETCH FLAGS 
> replies, so even if Dovecot did send them it wouldn't be of any use to 
> you.

I'm using Evolution 2.0.2 and the evo IMAP support has been rewritten a
couple of times since 1.4.x. (and is destined to be rewritten at least
once or twice more in the near future; perhaps IMAP isn't the easiest
spec to implement reliably  ;-) I think Evo does respond to FETCH FLAGS
now, so it might actually be of use. If it doesn't I can start writing
patches for Evolution, but there's no point really if the server doesn't
give them. This is a little bit of a chicken-and-egg problem, but it
seems like starting with the server would be easier, so why not start
there, since there's a good chance the client is already done?

On a related note about Evolution's IMAP support, there is a comment in
dovecot.conf in reference to mailbox_check_interval that says:

# NOTE: Evolution client breaks with this option when it's trying to APPEND.

This has been fixed for over a year.
http://bugzilla.ximian.com/show_bug.cgi?id=42573

cya,
.sig