Quoting Timo Sirainen tss@iki.fi:
On 10.5.2011, at 21.44, Michael M Slusarz wrote:
In a mailbox that has ACL restrictions on both DELETE and EXPUNGE
(i.e. no 'e' or 't' rights), I see the following:3 UID STORE 3173 (UNCHANGEDSINCE 353) +FLAGS \deleted 3 OK Store completed.
(UID 3173 is not flagged \deleted)
[...]
6 UID EXPUNGE 1:* 6 OK Expunge completed.
(At least 1 UID is flagged \deleted in mailbox)
Shouldn't these commands be returning "NO" instead of "OK"? RFC
3501 [6.4.6] for STORE:Clients aren't very happy about seeing NO. Also Dovecot didn't say
anything changed with either of the above commands, so nothing
really failed either. A "STORE +FLAGS.SILENT \Deleted" is more
controversial though. Maybe that should return NO..
I personally don't care about +FLAGS.SILENT, since ideally people
should be using CONDSTORE/QRESYNC :) - in which case FLAGS.SILENT is
irrelevant.
But as far as the NO for a non-silent STORE, it seems that RFC 4314
[4] disagrees with you:
STORE operation SHOULD NOT fail if the user has rights to modify
at least one flag specified in the STORE, as the tagged NO
response to a STORE command is not handled very well by deployed
clients.To me, the negative inference from this statement would be: "STORE
operation SHOULD fail if the user has no rights to modify at least one
flag specified in the STORE." So I would agree with your statement
that there should not be a NO response if at least one flag is
settable, but I disagree (and RFC 4314 seems to back me up) and
believe that there should be a NO if none of the flags given can be set.
At a minimum, a NOPERM response should be thrown, or else there is no
feedback at all why the flag was not set (without parsing ACLs).
Ideally a client should disable all features not available to the user
in the UI - something I am presently working on - but that should not
eliminate the need for useful error responses in order to determine if
the action was successful.
and RFC RFC 3501 [6.4.3] for EXPUNGE:
NO - expunge failure: can't expunge (e.g., permission denied)
Additionally, RFC 5530 [3] provides the NOPERM response code:
NOPERM The access control system (e.g., Access Control List (ACL), see [RFC 4314]) does not permit this user to carry out an operation, such as selecting or creating a mailbox.
C: f select "/archive/projects/experiment-iv" S: f NO [NOPERM] Access deniedMy reading of this is that NOPERM should be returned for ANY ACL
prohibited action, not just for selecting or creating a mailbox.
Dovecot 2.0.12 does not return NOPERM for DELETE/EXPUNGE actions
(at a minimum) that are prohibited.I'm not really sure. Maybe for EXPUNGE a NO would be okay. For flag
changes it's just annoying to see clients popup pointless error
messages when trying to set a \Seen flag (or \Answered flag when
replying).
That may be true, but if a user can't do something in a mailbox I
would rather have them be told of their limitations rather than have
them scratch their head while trying to figure out why things aren't
happening that they are explicitly (and, if failing, most likely
repeatedly) trying to do.
Alternatively, there doesn't seem to be any limitation to use NOPERM
with a NO response. Theoretically, you could issue an OK with NOPERM.
Clients are required to ignore response codes they don't recognize,
and those that do can make the determination whether any NOPERM,
regardless of status response, should be something they might be
interested in dealing with.
Also I'm not sure if Dovecot's behavior is entirely correct either
here. It might be more correct that all flag changes succeed, but
those flags would be session-only flag changes rather than permanent
flag changes.It's a slightly difficult subject :)
Discussion of session-only flags is all laid out in RFC 3501, so I can
vouch that *my* client software handles them correctly :) I can not
comment on the potential work needed on the server end.
michael