On Mon, 27 Jan 2003, Rick Block wrote: > I'm working on a server that cannot make a message unseen > once it's been marked seen. I've tried returning untagged > fetch responses to store attempts to clear the seen flag, > like so (assuming message 1 is already seen): > c: xyzzy store 1 -flags (\seen) > s: * 1 fetch (flags (\seen)) > s: xyzzy OK
This is the correct thing for your server to do. If your server supports ACL (RFC 2086), it should not offer the "s" right. Now, I would prefer that your server allow alteration of the \Seen flag, but it *is* compliant. If your server didn't support the \Seen flag at all, a better behavior would be to omit \Seen in the PERMANENTFLAGS list and allow setting/clearing \Seen in the session. What you have is slightly different; you have a flag that can be set but not cleared. > but the clients I've tried (Outlook Express 5 and a fairly > old version of Netscape Communicator) seem to completely > ignore the untagged response (the message starts out looking > seen in the client, after marking the message unseen via > their user interface even with the untagged fetch response > the message is displayed as unseen). I consider both of these clients to be broken. Your situation is one of the reasons why the STORE command returns an untagged FETCH. I bet that if you try it with Pine, you'll get the behavior that you expect. > I've tried a NO > response; this is treated as a protocol error by these > clients. I don't think that a NO response should ever be issued in response to a STORE. Either the STORE is syntactically valid (returns OK along with what really happened), or it is not (returns BAD). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
