On 1.12.2004, at 00:30, Aaron VanDevender wrote:
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?
Dovecot bug.
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 theory that could work for a single session, but I don't think it's such a good idea. It assumes that all clients want to know about all changes all the time. This isn't true for example for Pine, webmail+caching imap proxy, and other clients that just don't care and fetch only what they want to know.
And most of the clients that do want to know about all changes issue FETCH 1:* FLAGS right after SELECT in any case, making Dovecot only waste bandwidth with them. Evolution is about the only exception which doesn't do this.
Also if the connection gets closed, there is no longer any way to resend the flags because there's no way to identify one client from another.
The real solution for this is CONDSTORE extension which allows fetching only changed flags.
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 ;-)
Last I heard 2.0 has the same old IMAP code that has been there forever with only some minor fixes, but the rewritten IMAP code is included in the source tarball, just not built by default. Too bad it still doesn't have IDLE support.
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?
Dovecot behaves the same way as all other servers. It shows the changes for selected mailbox after each command. I think changing both of them to support CONDSTORE would be better idea.
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
Yes, but Dovecot 0.99.x codebase also is over a year old mostly and I try to avoid changing it much. In any case mailbox_check_interval is quite useless and I've removed it since. The clients that would be able to use it are the ones that support IDLE anyway.