considered to be the same command, e.g., both UID COPY and COPY
commands require the same set of rights.
The table below summarizes different rights or their combinations
that are required in order to perform different IMAP operations. As
it is not always possible to express complex right checking and
interactions, the description after the table should be used as the
primary reference.
+-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
|Operations\Rights | l | r | s | w | i | k | x | t | e | a |Any|Non|
+-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
| commands in authenticated state |
+-------------------------------------------------------------------+
| LIST | + | | | | | | | | | | | |
| SUBSCRIBE | * | | | | | | | | | | | * |
| UNSUBSCRIBE | | | | | | | | | | | | + |
| LSUB | * | | | | | | | | | | | * |
|CREATE (for parent)| | | | | | + | | | | | | |
| DELETE | | ? | | | | | + | ? | ? | | | |
| RENAME | | | | | | + | + | | | | | |
| SELECT/EXAMINE | | + | | | | | | | | | | |
| STATUS | | + | | | | | | | | | | |
| SETACL/DELETEACL | | | | | | | | | | + | | |
| GETACL/LISTRIGHTS | | | | | | | | | | + | | |
| MYRIGHTS | | | | | | | | | | | + | |
| APPEND | | | ? | ? | + | | | ? | | | | |
+-------------------------------------------------------------------+
| commands in selected state |
+-------------------------------------------------------------------+
| COPY | | | ? | ? | + | | | ? | | | | |
| EXPUNGE | | | | | | | | | + | | | |
| CLOSE | | | | | | | | | ? | | | |
| FETCH | | | ? | | | | | | | | | |
| STORE flags | | | ? | ? | | | | ? | | | | |
+-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
Note: for all commands in the selected state, the "r" is implied,
because it is required to SELECT/EXAMINE a mailbox. Servers are not
required to check presence of the "r" right once a mailbox is
successfully selected.
Legend:
+ - The right is required
* - Only one of the rights marked with * is required
(see description below)
? - The right is OPTIONAL (see description below)
"Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is
required
"Non" - No rights required to perform the command
Listing and subscribing/unsubscribing mailboxes:
LIST - "l" right is required. However, unlike other commands
(e.g., SELECT) the server MUST NOT return a NO response if it
can’t list a mailbox.
Note that if the user has "l" right to a mailbox "A/B", but not to
its parent mailbox "A", the LIST command should behave as if the
mailbox "A" doesn’t exist, for example:
C: A777 LIST "" *
S: * LIST (\NoInferiors) "/" "A/B"
S: * LIST () "/" "C"
S: * LIST (\NoInferiors) "/" "C/D"
S: A777 OK LIST completed
SUBSCRIBE - "l" right is required only if the server checks for
mailbox existence when performing SUBSCRIBE.
UNSUBSCRIBE - no rights required to perform this operation.
LSUB - "l" right is required only if the server checks for mailbox
existence when performing SUBSCRIBE. However, unlike other
commands (e.g., SELECT) the server MUST NOT return a NO response
if it can’t list a subscribed mailbox.
Mailbox management:
CREATE - "k" right on a nearest existing parent mailbox. When a
new mailbox is created, it SHOULD inherit the ACL from the parent
mailbox (if one exists) in the defined hierarchy.
DELETE - "x" right on the mailbox. Note that some servers don’t
allow to delete a non-empty mailbox. If this is the case, the
user would also need "r", "e", and "t" rights, in order to open
the mailbox and empty it.
The DELETE command MUST delete the ACL associated with the deleted
mailbox.
RENAME - Moving a mailbox from one parent to another requires the
"x" right on the mailbox itself and the "k" right for the new
parent. For example, if the user wants to rename the mailbox
named "A/B/C" to "D/E", the user must have the "x" right for the
mailbox "A/B/C" and the "k" right for the mailbox "D".
The RENAME command SHOULD NOT change the ACLs on the renamed
mailbox and submailboxes.
Copying or appending messages:
Before performing a COPY/APPEND command, the server MUST check if
the user has "i" right for the target mailbox. If the user
doesn’t have "i" right, the operation fails. Otherwise for each
copied/appended message the server MUST check if the user has
"t" right - when the message has \Deleted flag set
"s" right - when the message has \Seen flag set
"w" right - for all other message flags.
Only when the user has a particular right are the corresponding
flags stored for the newly created message. The server MUST NOT
fail a COPY/APPEND if the user has no rights to set a particular
flag.
Example: C: A003 MYRIGHTS TargetMailbox
S: * MYRIGHTS TargetMailbox rwis
S: A003 OK Myrights complete
C: A004 FETCH 1:3 (FLAGS)
S: * 1 FETCH (FLAGS (\Draft \Deleted)
S: * 2 FETCH (FLAGS (\Answered)
S: * 3 FETCH (FLAGS ($Forwarded \Seen)
S: A004 OK Fetch Completed
C: A005 COPY 1:3 TargetMailbox
S: A005 OK Copy completed
C: A006 SELECT TargetMailbox
...
S: A006 Select Completed
Let’s assume that the copied messages received message numbers
77:79.
C: A007 FETCH 77:79 (FLAGS)
S: * 77 FETCH (FLAGS (\Draft))
S: * 78 FETCH (FLAGS (\Answered))
S: * 79 FETCH (FLAGS ($Forwarded \Seen))
S: A007 OK Fetch Completed
\Deleted flag was lost on COPY, as the user has no "t" right in
the target mailbox.
If the MYRIGHTS command with the tag A003 would have returned:
S: * MYRIGHTS TargetMailbox rsti
the response from the FETCH with the tag A007 would have been:
C: A007 FETCH 77:79 (FLAGS)
S: * 77 FETCH (FLAGS (\Deleted))
S: * 78 FETCH (FLAGS ())
S: * 79 FETCH (FLAGS (\Seen))
S: A007 OK Fetch Completed
In the latter case, \Answered, $Forwarded, and \Draft flags were
lost on COPY, as the user has no "w" right in the target mailbox.
Expunging the selected mailbox:
EXPUNGE - "e" right on the selected mailbox.
CLOSE - "e" right on the selected mailbox. If the server is
unable to expunge the mailbox because the user doesn’t have the
"e" right, the server MUST ignore the expunge request, close the
mailbox, and return the tagged OK response.
Fetch information about a mailbox and its messages:
SELECT/EXAMINE/STATUS - "r" right on the mailbox.
FETCH - A FETCH request that implies setting \Seen flag MUST NOT
set it, if the current user doesn’t have "s" right.
Changing flags:
STORE - the server MUST check if the user has
"t" right - when the user modifies \Deleted flag
"s" right - when the user modifies \Seen flag
"w" right - for all other message flags.
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.
Changing ACLs:
SETACL/DELETEACL - "a" right on the mailbox.
Reading ACLs:
GETACL - "a" right on the mailbox.
MYRIGHTS - any of the following rights is required to perform the
operation: "l", "r", "i", "k", "x", "a".
LISTRIGHTS - "a" right on the mailbox.
5. Other Considerations
5.1. Additional Requirements and Implementation Notes
5.1.1. Servers
This document defines an additional capability that is used to
announce the list of extra rights (excluding the ones defined in RFC
2086) supported by the server. The set of rights MUST include "t",
"e", "x", and "k". Note that the extra rights can appear in any
order.
Example: C: 1 capability
S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+
ACL RIGHTS=texk
S: 1 OK completed
Any server implementing an ACL extension MUST accurately reflect the
current user’s rights in FLAGS and PERMANENTFLAGS responses.
Example: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
S: A142 OK [READ-WRITE] SELECT completed
C: A143 MYRIGHTS INBOX
S: * MYRIGHTS INBOX lrwis
S: A143 OK completed
Note that in order to get better performance the client MAY pipeline
SELECT and MYRIGHTS commands:
C: A142 SELECT INBOX
C: A143 MYRIGHTS INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
S: A142 OK [READ-WRITE] SELECT completed
S: * MYRIGHTS INBOX lrwis
S: A143 OK completed
Servers MAY cache the rights a user has on a mailbox when the mailbox
is selected, so that if a client’s rights on a mailbox are changed
with SETACL or DELETEACL, commands specific to the selected state
(e.g., STORE, EXPUNGE) might not reflect the changed rights until the
mailbox is re-selected. If the server checks the rights on each
command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if
they have changed. If such server detects that the user no longer
has read access to the mailbox, it MAY send an untagged BYE response
and close connection. It MAY also refuse to execute all commands
specific to the selected state until the mailbox is closed; however,
server implementors should note that most clients don’t handle NO
responses very well.
An ACL server MAY modify one or more ACLs for one or more identifiers
as a side effect of modifying the ACL specified in a
SETACL/DELETEACL. If the server does that, it MUST send untagged ACL
response(s) to notify the client about the changes made.
An ACL server implementation MUST treat received ACL modification
commands as a possible ambiguity with respect to subsequent commands
affected by the ACL, as described in Section 5.5 of [IMAP4]. Hence a
pipeline SETACL + MYRIGHTS is an ambiguity with respect to the
server, meaning that the server must execute the SETACL command to
completion before the MYRIGHTS. However, clients are permitted to
send such a pipeline.
5.1.2. Clients
The following requirement is put on clients in order to allow for
future extensibility. A client implementation that allows a user to
read and update ACLs MUST preserve unrecognized rights that it
doesn’t allow the user to change. That is, if the client
1) can read ACLs
and
2) can update ACLs
but
3) doesn’t allow the user to change the rights the client doesn’t
recognize, then it MUST preserve unrecognized rights.
Otherwise the client could risk unintentionally removing permissions
it doesn’t understand.
5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes
A particular ACL server implementation MAY allow "shared multiuser
access" to some mailboxes. "Shared multiuser access" to a mailbox
means that multiple different users are able to access the same
mailbox, if they have proper access rights. "Shared multiuser
access" to the mailbox doesn’t mean that the ACL for the mailbox is
currently set to allow access by multiple users. Let’s denote a
"shared multiuser write access" as a "shared multiuser access" when a
user can be granted flag modification rights (any of "w", "s", or
"t").
Section 4 describes which rights are required for modifying different
flags.
If the ACL server implements some flags as shared for a mailbox
(i.e., the ACL for the mailbox MAY be set up so that changes to those
flags are visible to another user), let’s call the set of rights
associated with these flags (as described in Section 4) for that
mailbox collectively as "shared flag rights". Note that the "shared
flag rights" set MAY be different for different mailboxes.
If the server doesn’t support "shared multiuser write access" to a
mailbox or doesn’t implement shared flags on the mailbox, "shared
flag rights" for the mailbox is defined to be the empty set.
Example 1: Mailbox "banan" allows "shared multiuser write access" and
implements flags \Deleted, \Answered, and $MDNSent as
shared flags. "Shared flag rights" for the mailbox "banan"
is a set containing flags "t" (because system flag
\Deleted requires "t" right) and "w" (because both
\Answered and $MDNSent require "w" right).
Example 2: Mailbox "apple" allows "shared multiuser write access" and
implements \Seen system flag as shared flag. "Shared flag
rights" for the mailbox "apple" contains "s" right
because system flag \Seen requires "s" right.
Example 3: Mailbox "pear" allows "shared multiuser write access" and
implements flags \Seen, \Draft as shared flags. "Shared
flag rights" for the mailbox "apple" is a set containing
flags "s" (because system flag \Seen requires "s" right)
and "w" (because system flag \Draft requires "w" right).
The server MUST include a READ-ONLY response code in the tagged OK
response to a SELECT command if none of the following rights is
granted to the current user:
"i", "e", and "shared flag rights"(***).
The server SHOULD include a READ-WRITE response code in the tagged OK
response if at least one of the "i", "e", or "shared flag
rights"(***) is granted to the current user.
(***) Note that a future extension to this document can extend the
list of rights that causes the server to return the READ-WRITE
response code.
Example 1 (continued): The user that has "lrs" rights for the mailbox
"banan". The server returns READ-ONLY
response code on SELECT, as none of "iewt"
rights is granted to the user.
Example 2 (continued): The user that has "rit" rights for the mailbox
"apple". The server returns READ-WRITE
response code on SELECT, as the user has "i"
right.
Example 3 (continued): The user that has "rset" rights for the
mailbox "pear". The server returns READ-WRITE
response code on SELECT, as the user has "e"
and "s" rights.
6. Security Considerations
An implementation MUST make sure the ACL commands themselves do not
give information about mailboxes with appropriately restricted ACLs.
For example, when a user agent executes a GETACL command on a mailbox
that the user has no permission to LIST, the server would respond to
that request with the same error that would be used if the mailbox
did not exist, thus revealing no existence information, much less the
mailbox’s ACL.
IMAP clients implementing ACL that are able to modify ACLs SHOULD
warn a user that wants to give full access (or even just the "a"
right) to the special identifier "anyone".
This document relies on [SASLprep] to describe steps required to
perform identifier canonicalization (preparation). The preparation
algorithm in SASLprep was specifically designed such that its output
is canonical, and it is well-formed. However, due to an anomaly
[PR29] in the specification of Unicode normalization, canonical
equivalence is not guaranteed for a select few character sequences.
Identifiers prepared with SASLprep can be stored and returned by an
ACL server. The anomaly affects ACL manipulation and evaluation of
identifiers containing the selected character sequences. These
sequences, however, do not appear in well-formed text. In order to
address this problem, an ACL server MAY reject identifiers containing
sequences described in [PR29] by sending the tagged BAD response.
This is in addition to the requirement to reject identifiers that
fail SASLprep preparation as described in Section 3.
Other security considerations described in [IMAP4] are relevant to
this document. In particular, ACL information is sent in the clear
over the network unless confidentiality protection is negotiated.
This can be accomplished either by the use of STARTTLS, negotiated
privacy protection in the AUTHENTICATE command, or some other
protection mechanism.
7. Formal Syntax
Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
in Section 9 of [IMAP4]. Elements not defined here can be found in
[ABNF] and [IMAP4].
Except as noted otherwise, all alphabetic characters are case
insensitive. The use of uppercase or lowercase characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
LOWER-ALPHA = %x61-7A ;; a-z
acl-data = "ACL" SP mailbox *(SP identifier SP
rights)
capability =/ rights-capa
;;capability is defined in [IMAP4]
command-auth =/ setacl / deleteacl / getacl /
listrights / myrights
;;command-auth is defined in [IMAP4]
deleteacl = "DELETEACL" SP mailbox SP identifier
getacl = "GETACL" SP mailbox
identifier = astring
listrights = "LISTRIGHTS" SP mailbox SP identifier
listrights-data = "LISTRIGHTS" SP mailbox SP identifier
SP rights *(SP rights)
mailbox-data =/ acl-data / listrights-data / myrights-data
;;mailbox-data is defined in [IMAP4]
mod-rights = astring
;; +rights to add, -rights to remove
;; rights to replace
myrights = "MYRIGHTS" SP mailbox
myrights-data = "MYRIGHTS" SP mailbox SP rights
new-rights = 1*LOWER-ALPHA
;; MUST include "t", "e", "x", and "k".
;; MUST NOT include standard rights listed
;; in section 2.2
rights = astring
;; only lowercase ASCII letters and digits
;; are allowed.
rights-capa = "RIGHTS=" new-rights