IMAP4 Access Control List (ACL) Extension
obsoletes
- rfc-2086 — IMAP4 ACL extension
Extracted elements (30)
GETACL requires the 'a' right rather than the 'r' right (as some implementations allowed) because if a user only has the 'r' right, GETACL can disclose information about identifiers existing on the mail system.
The 'd' right was split into 'e' (EXPUNGE), 't' (\Deleted flag), and possibly 'x' (DELETE mailbox) to resolve ambiguity in RFC 2086 where some implementations used 'c'/'d' differently. Virtual rights 'd' and 'c' are retained for backward compatibility with deployed RFC 2086 clients.
An ACL server MUST treat received ACL modification commands as a possible ambiguity with respect to subsequent commands, per Section 5.5 of RFC 3501. A pipelined SETACL + MYRIGHTS is ambiguous; the server must execute SETACL to completion before MYRIGHTS.
Negative rights (identifiers starting with '-') allow removal of rights from a specific identifier even if granted via another ACL entry. Server implementations are not required to support negative right identifiers, and DELETEACL does not affect negative right entries.
A client implementation that can read and update ACLs but doesn't allow the user to change rights it doesn't recognize MUST preserve unrecognized rights, to avoid unintentionally removing permissions it doesn't understand.
A FETCH request that implies setting the \Seen flag MUST NOT set it if the current user doesn't have the 's' right. STORE operations SHOULD NOT fail if the user has rights to modify at least one of the specified flags.
A server implementation conformant to this document MUST also return rights not defined in Section 2.2 in the 'RIGHTS=' capability. The set of rights MUST include 't', 'e', 'x', and 'k'.
Any server implementing the ACL extension MUST accurately reflect the current user's rights in FLAGS and PERMANENTFLAGS responses.
Before executing a command, an ACL-compliant server MUST check which rights are required to perform it. A summary table maps IMAP operations (LIST, SELECT, COPY, STORE, EXPUNGE, SETACL, etc.) to the required rights.
For COPY/APPEND, the server MUST check the 'i' right for the target mailbox first. For each message, the server MUST check 't' right when \Deleted flag is set, 's' when \Seen flag is set, and 'w' for all other flags. The server MUST NOT fail COPY/APPEND if the user lacks rights to set a particular flag; instead the flag is silently dropped.
Servers processing commands with an identifier parameter (SETACL, DELETEACL, LISTRIGHTS) SHOULD first prepare the identifier using the SASLprep profile of stringprep. If preparation fails or results in an empty string, the server MUST refuse the command with a BAD response.
The DELETE command MUST delete the ACL associated with the deleted mailbox. RENAME SHOULD NOT change the ACLs on the renamed mailbox and submailboxes.
The 'RIGHTS=' capability MUST NOT include any of the rights defined in RFC 2086: 'l', 'r', 's', 'w', 'i', 'p', 'a', 'c', 'd', and digits '0'..'9'.
The server MUST either grant all tied rights to the identifier in a mailbox or grant none. The same right MUST NOT be listed more than once in the LISTRIGHTS response.
The server MUST include a READ-ONLY response code in the tagged OK response to a SELECT command if none of the rights 'i', 'e', and 'shared flag rights' is granted to the current user. The server SHOULD include READ-WRITE if at least one of these rights is granted.
Uppercase rights are not allowed; the SETACL command MUST return a BAD response if uppercase rights are specified. An unrecognized right MUST cause the command to return the BAD response; the server MUST NOT silently ignore unrecognized rights.
When any of the 'create' member rights (k, possibly x) is set in a list of rights, the server MUST also include the 'c' right when returning the list in a MYRIGHTS or ACL response.
When any of the 'delete' member rights (e, t, x) is set in a list of rights, the server MUST also include the 'd' right when returning the list in a MYRIGHTS or ACL response, to enable older RFC 2086 clients to work with newer servers.
When CREATE is called, the new mailbox SHOULD inherit the ACL from the parent mailbox (if one exists) in the defined hierarchy.
An Access Control List (ACL) is a set of <access identifier, rights> pairs that applies to a mailbox name. Access identifiers are UTF-8 strings; 'anyone' is reserved for the universal identity. Rights is a string of alphanumeric characters controlling operations.
Standard rights are single lowercase letters: l (lookup/LIST), r (read/SELECT), s (seen flag), w (write flags), i (insert/APPEND), p (post), k (create mailboxes), x (delete mailbox), t (delete messages/\Deleted flag), e (EXPUNGE), a (administer ACLs).
The DELETEACL command removes any <identifier, rights> pair for the specified identifier from the ACL for the specified mailbox.
The LISTRIGHTS command takes a mailbox name and identifier and returns information about what rights can be granted to the identifier in the ACL for the mailbox. The LISTRIGHTS response includes required rights and zero or more sets of optional tied rights.
The SETACL command changes the ACL on a specified mailbox. The third argument is a string with an optional '+' (add rights) or '-' (remove rights) prefix followed by zero or more rights characters. Without a prefix, the rights replace existing rights for the identifier.
Virtual rights 'd' and 'c' exist for backward compatibility with RFC 2086. The 'd' right is a macro expanding to 'e', 't', and possibly 'x'; the 'c' right is a macro expanding to 'k' and possibly 'x'. Clients conforming to this document MUST ignore these virtual rights in MYRIGHTS, ACL, and LISTRIGHTS responses.
This document defines the 'RIGHTS=' IMAP capability, which announces the list of extra rights (beyond RFC 2086) supported by the server. IANA has added this capability to the IMAP4 capabilities registry.
ACL information is sent in the clear over the network unless confidentiality protection is negotiated, such as via STARTTLS, negotiated privacy in the AUTHENTICATE command, or another protection mechanism.
An implementation MUST ensure that ACL commands themselves do not reveal information about mailboxes with restricted ACLs. For example, GETACL on a mailbox the user cannot LIST must return the same error as if the mailbox did not exist.
Due to an anomaly (PR29) in Unicode normalization, canonical equivalence is not guaranteed for a select few character sequences when using SASLprep. An ACL server MAY reject identifiers containing these sequences by sending a BAD response.
IMAP clients implementing ACL that can modify ACLs SHOULD warn a user who wants to give full access (or even just the 'a' right) to the special identifier 'anyone'.