Mark, I'm 99% sure that there's text in the spec that indicates that
flag changes must take effect - they don't need to be permanent, but
they do need to take effect (as I mentioned in my previous mail, we got
burned by that on Exchange at one point). Obviously you wrote the text,
so you should know but let me see if I can find the reference....
<Time Passes>
Ah, here it is. Section 7.1:
PERMANENTFLAGS Followed by a parenthesized list of flags,
indicates which of the known flags that the client
can change permanently. Any flags that are in the
FLAGS untagged response, but not the PERMANENTFLAGS
list, can not be set permanently. If the client
attempts to STORE a flag that is not in the
PERMANENTFLAGS list, the server will either reject
it with a NO reply or store the state for the
remainder of the current session only. The
PERMANENTFLAGS list can also include the special
flag \*, which indicates that it is possible to
create new keywords by attempting to store those
flags in the mailbox.
Larry Osterman
-----Original Message-----
From: Mark Crispin [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 27, 2003 7:22 PM
To: Rick Block
Cc: [EMAIL PROTECTED]
Subject: Re: speaking of storing flags
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.
