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..
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).
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 :)