[Dovecot] automatic flag updates

[Timo Sirainen]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20041201/327a5106/attachment-0001.bin>