Outlook Express users are complaining that their message \Seen status is "lost". Snooping traffic, I see that OE is opening a second connection. In duplicating OE's behaviour by hand, I'm finding that I'm more confused than ever about Cyrus's behaviour. We're using Cyrus 2.1.9 on NetApp mounted disk.
First up, a description of what OE is doing (in all it's stupidity) - when you read a message, it uses BODY.PEEK so as not to update the \Seen flag. It then apparently closes that connection, opens another, and sets the \Seen status with "xxx UID STORE 49 +FLAGS.SILENT (\Seen)". It then forgets that connection, and opens a new connection and starts using that for accessing the mailbox. At the Cyrus end, this is useless - the Cyrus that accepts the \Seen update, but holds off updating the .seen file (presumably as a performance optimisation). So the second session doesn't see it until OE eventually closes the first connection. Even sending a NOOP on the \Seen-updating thread would have been enough to trigger Cyrus into updating the .seen file. Cyrus probably needs to update the .seen file if no other activity occurs for a second or two. But - there appears to be a second problem: even if OE had sent a NOOP (or Cyrus decided to write the file), the second session doesn't see the update - it's still holding open an old .seen file, now unlinked (by the rename() that the \Seen-updating thread did). Cyrus needs to periodically stat() the .seen file and compare it's inode number to that of the file it holds open - if the differ, it needs to reopen the file). The RFC isn't entirely helpful on who's at fault here - section 5.5 talks about multiple commands being allowed, provided ambiguity doesn't result. In this case, provided OE waits for the STORE command to complete, I guess it's within it's rights to check the message status from another session. It's largely irrelevant anyway - OE is out there, and getting it "fixed" would be a hiding to nothing. I realise this is an old known problem, but I've spent some time searching list archives, and other sources looking for an answer. Any help anyone can provide will be gratefully received. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
