draft-ietf-imapext-acl-04.txt   draft-ietf-imapext-acl-05.txt 
IMAPEXT Working Group A. Melnikov IMAPEXT Working Group A. Melnikov
Internet Draft Editor Internet Draft Editor
Document: draft-ietf-imapext-acl-04.txt June 2002 Document: draft-ietf-imapext-acl-05.txt June 2002
IMAP4 ACL extension IMAP4 ACL extension
Status of this Memo Status of this Memo
This document is an Internet Draft and is in full conformance with This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that Task Force (IETF), its Areas, and its Working Groups. Note that
skipping to change at line 40 skipping to change at line 40
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as a Proposed Standard for the Internet Community. Discussion editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested. Distribution of this and suggestions for improvement are requested. Distribution of this
draft is unlimited. draft is unlimited.
0. Open issues 0. Open issues
This section will be removed when the draft will be published as RFC. This section will be removed when the draft will be published as RFC.
It is intended to simplify discussion. It is intended to simplify discussion.
1). Should the document define exact syntax for identifiers starting 1). Require support for special identifier "disabled" for
with '$'? For example, the following was proposed by Mark Crispin: "ACL2=MOST-SPECIFIC" model?
Definable identifiers. Server implementations are *NOT* required to 2). Obsolete LISTRIGHTS?
use any of these, but if they do, these are their semantics. Note
that definable identifiers may expand to other definable identifiers.
$G$xxx global identifier xxx. Valid everywhere Mark Crispin wrote:
$U$xxx per-user identifier xxx. Valid only for the logged-in user
$M$xxx per-mailbox identifer xxx. Valid only for this mailbox
$xxxxx reserved for future definition
Non-definable identifiers. Server implementations SHOULD support $WORLD, > [...] If rights are tied in an
and MUST support anyone and user names. However, a server can respond > implementation, the implementation must be conservative in granting
with a NO. > 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. A client may discover the set of rights
> which may be granted to a given identifier in the ACL for a given
> mailbox by using the LISTRIGHTS command.
>
> This was in RFC 2086 as well.
>
> Do we really want these semantics?
>
> The effect of this is that it is mandatory to do a LISTRIGHTS prior to any
> SETACL (and multiple LISTRIGHTS prior to any REPLACEACL), since otherwise
> there is no way for a client to know how to grant a particular right to an
> identifier.
>
> Presumably, the reason for these semantics is so a client can review the
> impact of granting a particular right if it's tied to another. But will
> any client actually do this? Or will clients just blindly do the
> LISTRIGHTS to get the necessary incantation for SETACL?
>
> What I see is no savings of work for a client which cares about any side
> effects due to tied-rights, but a lot of extra work for clients which do
> not care.
$WORLD all authorized users but not anonymous Alexey Melnikov replied:
$ANONYMOUS anonymous users
$DISABLE disabled rights
2). Do we need a mechanism to encode login names if they start with I tend to agree. I would rather have a new response code LISTRIGHTS that is
$, -? returned in NO response to SETACL command.
Imagine that the client wants to grant "cp" rights to a user "smith". The
client instead of doing:
3). Should the annotations (ANNOTATE) be controlled by "w" right? C: A001 LISTRIGHTS ~/Mail/saved smith
S: * LISTRIGHTS ~/Mail/saved smith la r swi cdext
S: A001 OK Listrights completed
C: A002 SETACL ~/Mail/saved smith cdextp
S: A002 OK Setacl complete
4). Other editorial comments/questions are marked in the text with << and >>. will do the following (this assumes that the server doesn't want to grant a
right unless all tied rights are specified by the client):
C: A001 SETACL ~/Mail/saved smith cp
S: A001 NO [LISTRIGHTS la r swi cdext] No some rights are tied,
specify both
C: A002 SETACL ~/Mail/saved smith cdextp
S: A002 OK Setacl complete
C: A002 LISTRIGHTS ~/Mail/saved smith
and if the server sets all tied rights automatically if at least one of them
is specified (not recommended by the document but still possible):
C: A001 SETACL ~/Mail/saved smith cp
S: * ACL ~/Mail/saved smith cdextp
S: A001 OK Setacl complete
3). Other editorial comments/questions are enclosed in << and >>.
1. Abstract 1. Abstract
The ACL extension of the Internet Message Access Protocol [IMAP4] The ACL extension of the Internet Message Access Protocol [IMAP4]
permits access control lists to be manipulated through the IMAP permits access control lists to be manipulated through the IMAP
protocol. protocol.
2. Conventions Used in this Document 2. Conventions Used in this Document
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
skipping to change at line 92 skipping to change at line 130
document are to be interpreted as described in RFC 2119 [KEYWORDS]. document are to be interpreted as described in RFC 2119 [KEYWORDS].
3. Introduction and Overview 3. Introduction and Overview
The ACL extension is present in any IMAP4 implementation which The ACL extension is present in any IMAP4 implementation which
returns a capability starting with "ACL2=" as one of the supported returns a capability starting with "ACL2=" as one of the supported
capabilities to the CAPABILITY command. capabilities to the CAPABILITY command.
An access control list is a set of <identifier,rights> pairs. An access control list is a set of <identifier,rights> pairs.
Identifier is a UTF-8 string. All user name strings accepted by the LOGIN or Identifier is a UTF-8 string. An identifier may have one of the following
AUTHENTICATE commands to authenticate to the IMAP server are reserved forms:
as identifiers for the corresponding user. Identifiers starting with a). "anyone" - special identifier that refers to the universal identity
a dash ("-") are reserved for "negative rights", described below.
Several special identifiers are defined by this document:
a). The identifier "$anyone" is reserved to refer to the universal identity
(all authentications, including anonymous). (all authentications, including anonymous).
b). The identifier "$authuser" is reserved to refer to all authenticated users, b). "authuser" - special identifier that refer to all authenticated users,
but not anonymous. but not anonymous.
c). The identifier "$owner" refers to the owner of a mailbox (if any). c). "owner" - special identifier that refers to the owner of a mailbox
d). The identifier "$administrators" refers to all users with administrative rights. (if any).
d). "administrators" - special identifier that refers to all users with
administrative rights.
e). "user=<xxx>" - refers to a user. Here "<xxx>" is a user name string
accepted by the LOGIN or AUTHENTICATE commands.
f). "group=<xxx>" - refers to a group.
g). "-<identifier>", where <identifier> is one of a).-f). This is
reserved for "negative rights", described below.
<<Reserve X- and V- prefixes?>>
Note that a server is not required to implement any special identifier mentioned Note that a server is not required to implement any special identifier mentioned
above. However if it allows a user to perform ACL operations on any one of them, above. However if it allows a user to perform ACL operations on any one of them,
server MUST use the semantic as described above. server MUST use the semantic as described above.
All other identifiers starting with a dollar sign ("$") are reserved for All other identifier names are reserved for future definition in an
groups and implementation defined aliases. (As a consequence, user name strings extension or revision to this specification (also known as ACL2).
accepted by LOGIN or AUTHENTICATE MUST NOT start with "$".) All other identifier
strings are interpreted in an implementation-defined manner.
Rights is a string listing a (possibly empty) set of alphanumeric Rights is a string listing a (possibly empty) set of alphanumeric
characters, each character listing a set of operations which is being characters, each character listing a set of operations which is being
controlled. Letters are reserved for ''standard'' rights, listed controlled. Letters are reserved for ''standard'' rights, listed
below. The set of standard rights may only be extended by a below. The set of standard rights may only be extended by a
standards-track document. Digits are reserved for implementation or standards-track document. Digits are reserved for implementation or
site defined rights. The currently defined standard rights are: site defined rights. The currently defined standard rights are:
l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox) l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox)
r - read (SELECT the mailbox, perform STATUS, CHECK, FETCH, SEARCH, r - read (SELECT the mailbox, perform STATUS, CHECK, FETCH, SEARCH,
skipping to change at line 144 skipping to change at line 186
the parent mailbox (if one exists) in the defined hierarchy. the parent mailbox (if one exists) in the defined hierarchy.
x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag
during APPEND/COPY) during APPEND/COPY)
e - perform EXPUNGE and expunge as a part of CLOSE e - perform EXPUNGE and expunge as a part of CLOSE
d - This right is defined for backward compatibility with ACL d - This right is defined for backward compatibility with ACL
extension (RFC 2086). If a client sets "d" right, the server MUST extension (RFC 2086). If a client sets "d" right, the server MUST
set "x", "e" and "t" rights. When the client clears the "d" right, set "x", "e" and "t" rights. When the client clears the "d" right,
the server MUST clear "x", "e" and "t" rights. When all three of "x", the server MUST clear "x", "e" and "t" rights. When all three of "x",
"e" and "t" are set, the server MUST return "d" right in response to "e" and "t" are set, the server MUST return "d" right in response to
a GETACL command. If "x", "e" and "t" rights are not tied together, a ACL GET command. If "x", "e" and "t" rights are not tied together,
"d" right MUST NOT be returned in a LISTRIGHTS response. "d" right MUST NOT be returned in a ACL LIST response.
a - administer (perform SETACL and DELETEACL) a - administer (perform ACL STORE, ACL SET and ACL DELETE)
An implementation may tie rights together or may force rights to An implementation may tie rights together or may force rights to
always or never be granted to particular identifiers. For example, always or never be granted to particular identifiers. For example,
in an implementation that uses unix mode bits, the rights "wisd" are in an implementation that uses unix mode bits, the rights "wisd" are
tied, the "a" right is always granted to the owner of a mailbox and tied, the "a" right is always granted to the owner of a mailbox and
is never granted to another user. If rights are tied in an is never granted to another user. If rights are tied in an
implementation, the implementation must be conservative in granting implementation, the implementation must be conservative in granting
rights in response to SETACL commands--unless all rights in a tied rights in response to ACL STORE commands--unless all rights in a tied
set are specified, none of that set should be included in the ACL set are specified, none of that set should be included in the ACL
entry for that identifier. A client may discover the set of rights entry for that identifier. A client may discover the set of rights
which may be granted to a given identifier in the ACL for a given which may be granted to a given identifier in the ACL for a given
mailbox by using the LISTRIGHTS command. mailbox by using the ACL LIST command.
When an identifier in an ACL starts with a dash ("-"), that indicates When an identifier in an ACL starts with a dash ("-"), that indicates
that associated rights are to be removed from the identifier that is that associated rights are to be removed from the identifier that is
prefixed by the dash. This is referred to as a "negative right". For prefixed by the dash. This is referred to as a "negative right".
example, if the identifier "-fred" is granted the "w" right, that This differs from ACL DELETE in that a negative right is added to the
indicates that the "w" right is to be removed from users matching the ACL, and is part of the calculation of the rights.
identifier "fred". Server implementations are not required to
support "negative right" identifiers. For example, if the identifier "-user=fred" is granted the "w" right,
that indicates that the "w" right is to be removed from users matching
the identifier "user=fred", even though the user "fred" might have
the "w" right as a consequence of some other identifier in the ACL.
A ACL DELETE of "user=fred" simply deletes the identifier "user=fred"
from the ACL; it does not affect any rights that the user "fred"
may get from another ACL.
Server implementations are not required to support "negative right"
identifiers.
It is possible for multiple identifiers in an access control list to It is possible for multiple identifiers in an access control list to
apply to a given user (or other authentication identity). For apply to a given user (or other authentication identity). For
example, an ACL may include rights to be granted to the identifier example, an ACL may include rights to be granted to the identifier
matching the user, one or more implementation-defined identifiers matching the user, one or more implementation-defined identifiers
matching groups which include the user, and/or the identifier matching groups which include the user, and/or the identifier
"anyone". How these rights are combined to determine the user's "anyone". How these rights are combined to determine the user's
access is implementation-defined. The set of rules that describes access is implementation-defined. The set of rules that describes
how access is calculated is defined by a rule identifier (rule-ID). how access is calculated is defined by a rule identifier (rule-ID).
skipping to change at line 192 skipping to change at line 243
in order to calculate access, it MUST report "ACL2=UNION" in the server's in order to calculate access, it MUST report "ACL2=UNION" in the server's
capability list. capability list.
An implementation may instead choose to only use those rights granted An implementation may instead choose to only use those rights granted
to the most specific identifier present in the ACL. In this case the to the most specific identifier present in the ACL. In this case the
server MUST report "ACL2=MOST-SPECIFIC" in the server's capability server MUST report "ACL2=MOST-SPECIFIC" in the server's capability
list. list.
If the server implements any other policy for rights calculation, If the server implements any other policy for rights calculation,
it MUST be either registered with IANA using the template provided in 7.1 it MUST be either registered with IANA using the template provided in 7.1
or start with "X-". The server MUST report "ACL2=<rule-ID>" capability. or start with "X-". The server MUST report one and only one "ACL2=<rule-ID>"
capability in its CAPABILITY response.
3.1. Rights required to perform different IMAP4rev1 commands 3.1. Rights required to perform different IMAP4rev1 commands
Before executing a command an ACL2 compliant server must check which rights Before executing a command an ACL2 compliant server must check which rights
are required to perform it. This section groups command by functions are required to perform it. This section groups command by functions
they perform and list the rights required. It also gives the detailed description they perform and list the rights required. It also gives the detailed description
of any special processing required. of any special processing required.
Listing and subscribing/unsubscribing mailboxes: Listing and subscribing/unsubscribing mailboxes:
LIST - "l" right is required. LIST - "l" right is required.
skipping to change at line 259 skipping to change at line 311
Expunging the selected mailbox: Expunging the selected mailbox:
EXPUNGE - "e" right on the selected mailbox. EXPUNGE - "e" right on the selected mailbox.
CLOSE - "e" right on the selected mailbox. Server MUST NOT fail CLOSE operation if it is CLOSE - "e" right on the selected mailbox. Server MUST NOT fail CLOSE operation if it is
unable to expunge the mailbox. unable to expunge the mailbox.
Fetch information about a mailbox and its messages: Fetch information about a mailbox and its messages:
SELECT/EXAMINE/STATUS - "r" right on the mailbox. SELECT/EXAMINE/STATUS - "r" right on the mailbox.
CHECK - "r" right on the selected mailbox *. FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it, if the
current user doesn't have "s" right.
SEARCH - "r" right on the selected mailbox *.
FETCH - "r" right on the selected mailbox *, "s" right is required when FETCH implicitly
sets \Seen flag. FETCH operation MUST NOT fail if the server is required, but
unable to set \Seen flag.
* - no need to check explicitly, as "r" is required to open a mailbox in the first place.
Changing flags: Changing flags:
STORE - the server MUST check if the user has STORE - the server MUST check if the user has
"t" right - when the user modifies \Deleted flag "t" right - when the user modifies \Deleted flag
"s" right - when the user modifies \Seen flag "s" right - when the user modifies \Seen flag
"w" right for all other message flags. "w" right for all other message flags.
STORE operation SHOULD NOT fail if the user has rights to modify at least one flag STORE operation SHOULD NOT fail if the user has rights to modify at least one flag
specified in the STORE. specified in the STORE.
Changing ACLs: Changing ACLs:
SETACL/DELETEACL/REPLACEACL - "a" right on the mailbox. ACL STORE/DELETE/SET - "a" right on the mailbox.
Reading ACLs: Reading ACLs:
GETACL - "a" right on the mailbox. ACL GET - "a" right on the mailbox.
<<Several implementations allow GETACL with "r" right. If this is allowed, GETACL can <<Several implementations allow GETACL (ACL GET) with "r" right. If this is allowed,
disclose some identifiers existing on a mail system>> ACL GET can disclose some identifiers existing on a mail system>>
LISTRIGHTS -
<<Same rights as for GETACL?>>
MYRIGHTS - any of the following rights is required to perform the operation: MYRIGHTS - any of the following rights is required to perform the operation:
"l", "r", "i", "c", "x", "e", "a". "l", "r", "i", "c", "x", "e", "a".
ACL LIST - same as for MYRIGHTS.
4. Commands 4. Commands
4.1. SETACL 4.1. ACL STORE
Arguments: mailbox name Arguments: mailbox name
authentication identifier authentication identifier
access right modification access right modification
Data: no specific data for this command Data: OPTIONAL untagged responses: ACLINFO
Result: OK - setacl completed Result: OK - ACL STORE completed
NO - setacl failure: can't set acl NO - ACL STORE failure: can't set acl
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The SETACL command changes the access control list on the The ACL STORE command changes the access control list on the
specified mailbox so that the specified identifier is granted specified mailbox so that the specified identifier is granted
permissions as specified in the third argument. permissions as specified in the third argument.
The third argument is a string containing an optional plus ("+") The third argument is a string containing an optional plus ("+")
or minus ("-") prefix, followed by zero or more rights characters. or minus ("-") prefix, followed by zero or more rights characters.
If the string starts with a plus, the following rights are added If the string starts with a plus, the following rights are added
to any existing rights for the identifier. If the string starts to any existing rights for the identifier. If the string starts
with a minus, the following rights are removed from any existing with a minus, the following rights are removed from any existing
rights for the identifier. If the string does not start with a rights for the identifier. If the string does not start with a
plus or minus, the rights replace any existing rights for the plus or minus, the rights replace any existing rights for the
identifier. identifier.
4.2. DELETEACL Note, that for "ACL2=UNION" access calculation rule
<ACL STORE mailbox identifier ""> MUST be treated as
<ACL DELETE mailbox identifier>. Also note that these two commands
don't have the same result for "ACL2=MOST-SPECIFIC".
An ACL2 server MAY modify one or more ACL for one or more identifier
as a side effect of modifying the ACL specified in ACL STORE. If the
server does that it MUST send untagged ACLINFO response to notify the
client about the changes made.
4.2. ACL DELETE
Arguments: mailbox name Arguments: mailbox name
authentication identifier authentication identifier
Data: no specific data for this command Data: OPTIONAL untagged responses: ACLINFO
Result: OK - deleteacl completed Result: OK - ACL DELETE completed
NO - deleteacl failure: can't delete acl NO - ACL DELETE failure: can't delete acl
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The DELETEACL command removes any <identifier,rights> pair for the The ACL DELETE command removes any <identifier,rights> pair for the
specified identifier from the access control list for the specified identifier from the access control list for the
specified mailbox. specified mailbox.
4.3. REPLACEACL An ACL2 server MAY modify one or more ACL for one or more identifier
as a side effect of modifying the ACL specified in ACL DELETE. If the
server does that it MUST send untagged ACLINFO response to notify the
client about the changes made.
4.3. ACL SET
Arguments: mailbox name Arguments: mailbox name
list of (authentication identifier, access rights) pairs list of (authentication identifier, access rights) pairs
Data: no specific data for this command Data: OPTIONAL untagged responses: ACLINFO
Result: OK - replaceacl completed Result: OK - replaceacl completed
NO - replaceacl failure: can't replace acl NO - replaceacl failure: can't replace acl
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The REPLACEACL command replaces the access control list of the The ACL SET command replaces the access control list of the
specified mailbox with the one provided as the second parameter to specified mailbox with the one provided as the second parameter to
REPLACEACL. This command is semantically equivalent to the following ACL SET. This command is semantically equivalent to the following
sequence of commands: sequence of commands:
1). GETACL <mailbox name> 1). ACL GET <mailbox name>
2). For each (authentication identifier AID, access rights RD) pair returned 2). For each (authentication identifier AID, access rights RD) pair returned
in the untagged ACL response that was caused by GETACL, perform in the untagged ACL response that was caused by ACL GET, perform
DELETEACL <mailbox name> AID ACL DELETE <mailbox name> AID
3). For each (authentication identifier AIA, access rights RA) pair from 3). For each (authentication identifier AIA, access rights RA) pair from
the second parameter of REPLACEACL perform the second parameter of ACL SET perform
SETACL <mailbox name> AIA RA ACL STORE <mailbox name> AIA RA
4.4. GETACL An ACL2 server MAY modify one or more ACL for one or more identifier
as a side effect of modifying the ACL specified in ACL SET. If the
server does that it MUST send untagged ACLINFO response to notify the
client about the changes made.
4.4. ACL GET
Arguments: mailbox name Arguments: mailbox name
Data: untagged responses: ACL Data: REQUIRED untagged responses: ACLINFO
Result: OK - getacl completed Result: OK - ACL GET completed
NO - getacl failure: can't get acl NO - ACL GET failure: can't get acl
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The GETACL command returns the access control list for mailbox in The ACL GET command returns the access control list for mailbox in
an untagged ACL reply. an untagged ACLINFO reply.
Example: C: A002 GETACL INBOX Example: C: A002 ACL GET INBOX
S: * ACL INBOX Fred rwipslextda S: * ACLINFO INBOX user=Fred rwipslextda
S: A002 OK Getacl complete S: A002 OK acl get complete
4.5. LISTRIGHTS 4.5. ACL LIST
Arguments: mailbox name Arguments: mailbox name
authentication identifier authentication identifier
Data: untagged responses: LISTRIGHTS Data: untagged responses: RIGHTS-INFO
Result: OK - listrights completed Result: OK - ACL LIST completed
NO - listrights failure: can't get rights list NO - ACL LIST failure: can't get rights list
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The LISTRIGHTS command takes a mailbox name and an identifier and The ACL LIST command takes a mailbox name and an identifier and
returns information about what rights may be granted to the returns information about what rights may be granted to the
identifier in the ACL for the mailbox. identifier in the ACL for the mailbox.
Example: C: a001 LISTRIGHTS ~/Mail/saved smith Example: C: a001 ACL LIST ~/Mail/saved user=smith
S: * LISTRIGHTS ~/Mail/saved smith la r swi cdext S: * RIGHTS-INFO ~/Mail/saved user=smith la r swi cdext
S: a001 OK Listrights completed S: a001 OK ACL LIST completed
C: a005 LISTRIGHTS archive.imap anyone C: a005 ACL LIST archive.imap anyone
S: * LISTRIGHTS archive.imap anyone "" l r s w i p c dtex a S: * RIGHTS-INFO archive.imap anyone "" l r s w i p c dtex a
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
S: a005 OK Listrights completed S: a005 OK ACL LIST completed
4.6. MYRIGHTS 4.6. MYRIGHTS
Arguments: mailbox name Arguments: mailbox name
Data: untagged responses: MYRIGHTS Data: untagged responses: MYRIGHTS
Result: OK - myrights completed Result: OK - myrights completed
NO - myrights failure: can't get rights NO - myrights failure: can't get rights
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The MYRIGHTS command returns the set of rights that the user has The MYRIGHTS command returns the set of rights that the user has
to mailbox in an untagged MYRIGHTS reply. to mailbox in an untagged MYRIGHTS reply.
<<There is a proposal to replace MYRIGHT with either ACL FETCH or ACL CHECK:
ACL FETCH is slightly different than MYRIGHTS in that it takes an identifier
as an argument and returns the rights for that identifier (?? is this
desirable ??).
Or perhaps there could be an ACL CHECK that, given an identifier and a set of
right, returns whether or not that identifier has those rights. ACL CHECK
is probably more useful.
For now MYRIGHTS is left as is, because neither parameters, nor responses were
affected by the change to identifiers. However, if there is a desire to
accept multiple mailboxes or mailbox masks in MYRIGHT, it would be better to
change it to ACL <something> as well.>>
The user must have any of the following rights to perform this operation: The user must have any of the following rights to perform this operation:
"l", "r", "i", "c", "x", "e", "a". "l", "r", "i", "c", "x", "e", "a".
If the user doesn't have any right from the above list, the server If the user doesn't have any right from the above list, the server
MUST behave as if the mailbox doesn't exist. MUST behave as if the mailbox doesn't exist.
Example: C: A003 MYRIGHTS INBOX Example: C: A003 MYRIGHTS INBOX
S: * MYRIGHTS INBOX rwipsldexta S: * MYRIGHTS INBOX rwipsldexta
S: A003 OK Myrights complete S: A003 OK Myrights complete
5. Responses 5. Responses
5.1. ACL 5.1. ACLINFO
Data: mailbox name Data: mailbox name
zero or more identifier rights pairs zero or more identifier rights pairs
The ACL response occurs as a result of a GETACL command. The The ACLINFO response occurs as a result of a ACL GET command. It MAY
first string is the mailbox name for which this ACL applies. This also occur as a result of ACL STORE/DELETE/SET. The first string
is followed by zero or more pairs of strings, each pair contains is the mailbox name for which this ACL applies. This is followed
the identifier for which the entry applies followed by the set of by zero or more pairs of strings, each pair contains the identifier
rights that the identifier has. for which the entry applies followed by the set of rights that the
identifier has.
5.2. LISTRIGHTS << There is a proposal to use LISTEXT syntax instead. This requires
publishing a new revision of LISTEXT, that in its current form, is not
flexible enough. >>
5.2. RIGHTS-INFO
Data: mailbox name Data: mailbox name
identifier identifier
required rights required rights
list of optional rights list of optional rights
The LISTRIGHTS response occurs as a result of a LISTRIGHTS The RIGHTS-INFO response occurs as a result of a ACL LIST
command. The first two strings are the mailbox name and command. The first two strings are the mailbox name and
identifier for which this rights list applies. Following the identifier for which this rights list applies. Following the
identifier is a string containing the (possibly empty) set of identifier is a string containing the (possibly empty) set of
rights the identifier will always be granted in the mailbox. rights the identifier will always be granted in the mailbox.
Following this are zero or more strings each containing a set of Following this are zero or more strings each containing a set of
rights the identifier may be granted in the mailbox. Rights rights the identifier may be granted in the mailbox. Rights
mentioned in the same string are tied together--either all must be mentioned in the same string are tied together--either all must be
granted to the identifier in the mailbox or none may be granted. granted to the identifier in the mailbox or none may be granted.
The same right may not be listed more than once in the LISTRIGHTS The same right may not be listed more than once in the RIGHTS-INFO
command. response.
5.3. MYRIGHTS untagged response 5.3. MYRIGHTS untagged response
Data: mailbox name Data: mailbox name
rights rights
The MYRIGHTS response occurs as a result of a MYRIGHTS command. The MYRIGHTS response occurs as a result of a MYRIGHTS command.
The first string is the mailbox name for which these rights apply. The first string is the mailbox name for which these rights apply.
The second string is the set of rights that the client has. The second string is the set of rights that the client has.
skipping to change at line 485 skipping to change at line 569
Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
Non-terminals referenced but not defined below are as defined by Non-terminals referenced but not defined below are as defined by
[IMAP4]. [IMAP4].
Except as noted otherwise, all alphabetic characters are Except as noted otherwise, all alphabetic characters are
case-insensitive. The use of upper or lower case characters to case-insensitive. The use of upper or lower case characters to
define token strings is for editorial clarity only. Implementations define token strings is for editorial clarity only. Implementations
MUST accept these strings in a case-insensitive fashion. MUST accept these strings in a case-insensitive fashion.
acl_data = "ACL" SPACE mailbox *(SPACE identifier SPACE rights) acl2_command = myrights | "ACL" SPACE acl2_subcommand
deleteacl = "DELETEACL" SPACE mailbox SPACE identifier acl2_subcommand = replaceacl | deleteacl | updateacl | getacl | listrights
getacl = "GETACL" SPACE mailbox acl_data = "ACLINFO" SPACE mailbox *(SPACE identifier SPACE rights)
always_granted = rights
deleteacl = "DELETE" SPACE mailbox SPACE identifier
getacl = "GET" SPACE mailbox
identifier = astring identifier = astring
;; UTF-8 ;; UTF-8
listrights = "LISTRIGHTS" SPACE mailbox SPACE identifier << Specify more detailed syntax for identifiers? >>
listrights_data = "LISTRIGHTS" SPACE mailbox SPACE identifier listrights = "LIST" SPACE mailbox SPACE identifier
SPACE rights *(SPACE rights)
mod_rights = astring listrights_data = "RIGHTS-INFO" SPACE mailbox SPACE identifier
SPACE always_granted *(SPACE rights)
mod_rights = quoted
;; +rights to add, -rights to remove ;; +rights to add, -rights to remove
myrights = "MYRIGHTS" SPACE mailbox myrights = "MYRIGHTS" SPACE mailbox
myrights_data = "MYRIGHTS" SPACE mailbox SPACE rights myrights_data = "MYRIGHTS" SPACE mailbox SPACE rights
myrights_rspcod = "MYRIGHTS" SPACE rights myrights_rspcod = "MYRIGHTS" SPACE rights
replaceacl = "REPLACEACL" SPACE mailbox *(SPACE identifier SPACE rights) replaceacl = "SET" SPACE mailbox *(SPACE identifier SPACE rights)
resp-text-code =/ myrights_data resp-text-code =/ myrights_data
rights = astring rights = quoted
;; MUST NOT contain leading "+" or "-"
setacl = "SETACL" SPACE mailbox SPACE identifier SPACE mod_rights updateacl = "STORE" SPACE mailbox SPACE identifier SPACE mod_rights
7. IANA considerations 7. IANA considerations
7.1. ACL access calculation rule Registration Template 7.1. ACL access calculation rule Registration Template
When an access calculation rule for ACL2 extension is registered, the When an access calculation rule for ACL2 extension is registered, the
following information is supplied: following information is supplied:
Rule Identification: specify a string that identifies this Rule Identification: specify a string that identifies this
rule. Unless the rule is registered with the IANA, the rule. Unless the rule is registered with the IANA, the
skipping to change at line 584 skipping to change at line 677
Special Identifiers: No. Special Identifiers: No.
Contact Information: c.f., the "Editor's Address" section of this Contact Information: c.f., the "Editor's Address" section of this
memo memo
9. Security Considerations 9. Security Considerations
An implementation must make sure the ACL commands themselves do not An implementation must make sure the ACL commands themselves do not
give information about mailboxes with appropriately restricted ACL's. give information about mailboxes with appropriately restricted ACL's.
For example, a GETACL command on a mailbox for which the user has For example, a ACL GET command on a mailbox for which the user has
insufficient rights should not admit the mailbox exists, much less insufficient rights should not admit the mailbox exists, much less
return the mailbox's ACL. return the mailbox's ACL.
IMAP clients implementing ACL2 that are able to modify ACLs SHOULD
warn a user that wants to give full access to the special identifier
"anyone".
10. Other considerations 10. Other considerations
10.1. Compatibility with RFC 2086 10.1. Compatibility with RFC 2086
Any server that prohibits a user name in LOGIN/AUTHENTICATE that starts << This has to be written >>
with "$" MUST report "ACL" capability in addition to a "ACL=..." capability.
10.2. ACL2 interaction with QUOTA extension 10.2. ACL2 interaction with QUOTA extension
Server that implement both ACL2 and QUOTA extensions MUST use the following Server that implement both ACL2 and QUOTA extensions MUST use the following
table to determine if a quote operation should be allowed for the user: table to determine if a quote operation should be allowed for the user:
GETQUOTAROOT - "r" right GETQUOTAROOT - "r" right
<< Replace with/add "a" and "i"? >>
GETQUOTA - no rights required GETQUOTA - no rights required
SETQUOTA - "a" right SETQUOTA - implementation defined, as SETQUOTA operates on a quotaroot,
not on a mailbox.
<< Some implementations allows to set quota when the user has "r" right as well. 10.3. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes.
Should we allow that? >>
10.3. Additional requirements and Implementation notes A particular ACL2 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 may be
granted flag modification rights (any of "w", "s" or "t").
Section 3.1 ("Rights required to perform different IMAP4rev1 commands")
describes which rights are required for modifying different flags.
If the ACL2 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 3.1) for that mailbox collectively as "shared flag
rights". Note, that "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).
<<Editor: I know this looks ugly, but this is required for interoperability.
Please check whether this makes any sense!>>
The server MUST include a READ-ONLY prefix in the tagged OK response to
a SELECT command if all of the following rights are not granted to the
current user:
"i", "e" and "shared flag rights".
The server SHOULD include a READ-WRITE prefix in the tagged OK response
if either of the "i", "e" or "shared flag rights" is granted to the
current user.
<<Continue examples 1-3>>
10.4. Additional requirements and Implementation notes
Any server implementing an ACL2 extension MUST accurately reflect the current Any server implementing an ACL2 extension MUST accurately reflect the current
user's rights in FLAGS and PERMANENTFLAGS responses. The server SHOULD issue user's rights in FLAGS and PERMANENTFLAGS responses. The server SHOULD issue
a MYRIGHTS response code in an untagged OK response as a result of a SELECT a MYRIGHTS response code in an untagged OK response as a result of a SELECT
or EXAMINE command. or EXAMINE command.
Example: C: A142 SELECT INBOX Example: C: A142 SELECT INBOX
S: * 172 EXISTS S: * 172 EXISTS
S: * 1 RECENT S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: * OK [MYRIGHTS rwiste] Allowed rights S: * OK [MYRIGHTS rwiste] Allowed rights
S: A142 OK [READ-WRITE] SELECT completed S: A142 OK [READ-WRITE] SELECT completed
An ACL2 server is allowed to add/remove some rights An ACL2 server MAY modify one or more ACL for one or more identifier as a
automatically when executing any of SETACL/DELETEACL/REPLACEACL. If the side effect of modifying the ACL specified in ACL STORE/DELETE/SET.
server does that it MUST send untagged ACL response to notify the client If the server does that it MUST send untagged ACL response to notify the
about the changes made. client about the changes made.
11. References 11. References
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997. Requirement Levels", RFC 2119, Harvard University, March 1997.
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
November 1997. November 1997.
skipping to change at line 654 skipping to change at line 805
[UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646",
RFC 2279, Alis Technologies, January 1998. RFC 2279, Alis Technologies, January 1998.
[QUOTA] Myers, J., "IMAP4 QUOTA extension", RFC 2087, Carnegie Mellon [QUOTA] Myers, J., "IMAP4 QUOTA extension", RFC 2087, Carnegie Mellon
University, January 1997. University, January 1997.
12. Aknowledgement 12. Aknowledgement
This document is a revision of the RFC 2086 written by John G. Myers. This document is a revision of the RFC 2086 written by John G. Myers.
Editor also appreciate comments received from Mark Crispin, Chris Newman, Editor appreciates comments received from Mark Crispin, Chris Newman,
Cyrus Daboo, Curtis King, Lyndon Nerenberg and other members of IMAPEXT Cyrus Daboo, John G. Myers, Curtis King, Lyndon Nerenberg, Larry Greenfield,
working group. Vladimir Butenko, Dave Cridland and other members of IMAPEXT working group.
13. Editor's Address 13. Editor's Address
Alexey Melnikov Alexey Melnikov
mailto: mel@messagingdirect.com mailto: mel@messagingdirect.com
ACI WorldWide/MessagingDirect ACI WorldWide/MessagingDirect
22 The Quadrant, Richmond, 22 The Quadrant, Richmond,
Surrey, United Kingdom, TW9 1BP Surrey, United Kingdom, TW9 1BP
skipping to change at line 699 skipping to change at line 850
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix A. Changes since RFC 2086 Appendix A. Changes since RFC 2086
1. Changed the charset of "identifier" from US-ASCII to UTF-8. 1. Changed the charset of "identifier" from US-ASCII to UTF-8.
2. Specified that identifiers starting with a dollar sign ("$") are 2. Changed identifier syntax. Now all users must start with "user="
prefix. Specified that identifiers starting with a "group=" prefix are
reserved for groups and implementation defined aliases. reserved for groups and implementation defined aliases.
3. Specified that mailbox deletion is controled by the "x" right and 3. Specified that mailbox deletion is controled by the "x" right and
EXPUNGE is controlled by "e" right. EXPUNGE is controlled by "e" right.
4. Clarified that RENAME requires "c" right for the new parent and "x" 4. Clarified that RENAME requires "c" right for the new parent and "x"
right for the old name. right for the old name.
5. Changed capability name from "ACL" to "ACL2" because changes 2 and 3 5. Changed capability name from "ACL" to "ACL2" because changes 2 and 3
are not backward compatible with ACL RFC. are not backward compatible with ACL RFC.
skipping to change at line 736 skipping to change at line 888
12. Added note about compatibility with RFC 2086 12. Added note about compatibility with RFC 2086
13. Added "Implementation Notes" section. 13. Added "Implementation Notes" section.
14. Updated "References" section. 14. Updated "References" section.
15. Deleted "PARTIAL", this is a depricated feature of RFC1730. 15. Deleted "PARTIAL", this is a depricated feature of RFC1730.
16. Added MYRIGHT response code as per Cyrus suggestion. 16. Added MYRIGHT response code as per Cyrus suggestion.
17. Added REPLACEACL as per Mark and Cyrus request. 17. Added REPLACEACL (ACL SET) as per Mark and Cyrus request.
18. Added new section that describes which rights are required and/or 18. Added new section that describes which rights are required and/or
checked when performing various IMAP commands. checked when performing various IMAP commands.
19. Added section about interaction of ACL2 with the QUOTA extension. 19. Added section about interaction of ACL2 with the QUOTA extension.
20. Added special identifiers "authuser", "owner" and "administrators".
21. Added mail client security considerations when dealing with special
identifier "anyone".
22. Clarified that negative rights are not the same as DELETEACL (ACL DELETE).
23. Removed the requirement to check the "r" right for CHECK, SEARCH and
FETCH, as this is required for SELECT/EXAMINE to be successful.
24. Added note that a server can modify an ACL for any identifier(s) as a
side effect of performing SETACL/DELETEACL/REPLACEACL
(ACL STORE/DELETE/SET). Also specified that the server MUST send
untagged ACL response if it does that. Updated command definition
to include optional ACL untagged response.
25. Fixed typo in 10.1. (Was "ACL=...", not "ACL2=...")
26. Cleaned up section 10.2 a bit.
27. LISTRIGHTS (ACL LIST) requires same rights as MYRIGHTS.
28. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY
response codes.
29. Changed ABNF for rigths/mod_rights to be quoted instead of astring.
30. Changed syntax of ACL2 commands according to the following table:
SETACL => ACL STORE
DELETEACL => ACL DELETE
REPLACEACL => ACL SET
GETACL => ACL GET
LISTRIGHTS => ACL LIST
MYRIGHTS was left as is
Changed syntax of ACL2 responses:
ACL => ACLINFO
LISTRIGHTS => RIGHTS-INFO
MYRIGHTS was left as is
Any better suggestions for names are welcome.
To Do List:
1). Cleanup appendix A before publication as RFC, as some changes don't
apply to RFC 2086.
2). Editorial: Convert to nroff, Word or XML format.
3). Update syntax to allow for multiple mailboxes and masks.
Describe partial failures.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/