IMAP4 ACL extension
obsoleted by
- rfc-4314 — IMAP4 Access Control List (ACL) Extension
Extracted elements (18)
How multiple identifiers in an ACL apply to a given user is implementation-defined. An implementation may use the union of rights granted to all applicable identifiers, or may use only those rights granted to the most specific identifier present. Clients can use MYRIGHTS to determine the effective rights.
Identifiers starting with '-' represent negative rights: granting '-fred' the 'w' right means the 'w' right is removed from users matching 'fred'. Implementations need not support negative-rights identifiers in ACLs.
The ACL extension is only present in IMAP4 implementations that return 'ACL' as one of the supported capabilities in response to the CAPABILITY command.
If rights are tied in an implementation, the implementation must be conservative in granting rights in response to SETACL commands: unless all rights in a tied set are specified, none of that set should be included in the ACL entry for that identifier.
Implementations MUST accept all alphabetic characters in ACL command and response token strings in a case-insensitive fashion.
The set of standard rights may only be extended by a standards-track document. Digits are reserved for implementation or site-defined rights.
An access control list (ACL) is a set of <identifier, rights> pairs. The identifier 'anyone' is reserved for the universal identity (all authentications including anonymous); identifiers matching LOGIN/AUTHENTICATE usernames are reserved for those users; identifiers starting with '-' denote negative rights.
The DELETEACL command removes any <identifier, rights> pair for the specified identifier from the ACL for the specified mailbox.
The GETACL command returns the full access control list for a mailbox in an untagged ACL reply containing zero or more identifier-rights pairs.
The LISTRIGHTS command takes a mailbox name and identifier and returns information about what rights may be granted to the identifier: the always-granted rights string and zero or more optional rights strings where rights in the same string are tied together.
The MYRIGHTS command returns, in an untagged MYRIGHTS reply, the set of effective rights that the currently logged-in user has on the specified mailbox.
The SETACL command changes the ACL on a specified mailbox for a given identifier. The third argument is an access right modification string with an optional '+' (add rights), '-' (remove rights), or no prefix (replace rights), followed by zero or more rights characters.
The standard rights are single alphanumeric characters: l (lookup/LIST), r (read/SELECT), s (keep seen/unseen across sessions), w (write flags), i (insert/APPEND/COPY into), p (post mail), c (create sub-mailboxes), d (delete/EXPUNGE), a (administer/SETACL). Letters are reserved for standard rights; digits are reserved for implementation- or site-defined rights.
An implementation must ensure that ACL commands do not reveal information about mailboxes with appropriately restricted ACLs. For example, a GETACL command on a mailbox for which the user has insufficient rights should not admit the mailbox exists, much less return its ACL.
The ACL untagged response carries the mailbox name followed by zero or more space-separated identifier/rights string pairs: 'ACL' SP mailbox *(SP identifier SP rights).
The LISTRIGHTS untagged response carries mailbox name, identifier, the always-granted rights string, and zero or more optional tied-rights strings: 'LISTRIGHTS' SP mailbox SP identifier SP rights *(SP rights). Rights in the same string are tied together.
The mod_rights field in SETACL is defined as an astring with optional '+' or '-' prefix followed by rights characters. Identifier and rights fields are both astrings as defined by IMAP4.
The MYRIGHTS untagged response carries two strings: the mailbox name and the effective rights string for the authenticated client: 'MYRIGHTS' SP mailbox SP rights.