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