draft-ietf-imapext-2086upd-02.txt   draft-ietf-imapext-2086upd-03.txt 
IMAPEXT Working Group A. Melnikov IMAPEXT Working Group A. Melnikov
Internet Draft Editor Internet Draft Editor
Document: draft-ietf-imapext-2086upd-02.txt December 2004 Document: draft-ietf-imapext-2086upd-03.txt February 2005
Updates: <<3501?>> Updates: <<3501?>>
Obsoletes: 2086 Obsoletes: 2086
Expires: June 2005 Expires: August 2005
IMAP4 ACL extension IMAP4 ACL extension
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, or patent or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be disclosed, will be disclosed, and any of which I become aware will be disclosed,
in accordance with RFC 3668. in accordance with RFC 3668.
skipping to change at line 44 skipping to change at line 45
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.
Abstract Abstract
The ACL (Access Control List) extension (RFC 2086) of the Internet The ACL (Access Control List) extension (RFC 2086) of the Internet
Message Access Protocol (IMAP4rev1) permits mailbox access control Message Access Protocol (IMAP4rev1) permits mailbox access control
lists to be manipulated through the IMAP protocol. lists to be retrieved and manipulated through the IMAP protocol.
This document is a revision of the RFC 2086. It defines several new This document is a revision of the RFC 2086. It defines several new
access control rights and clarifies which rights are required for access control rights and clarifies which rights are required for
different IMAP commands. different IMAP commands.
1. Conventions Used in this Document 1. 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
server respectively. server respectively.
skipping to change at line 79 skipping to change at line 80
[UTF-8] in identifiers, which rights are required for different IMAP4 [UTF-8] in identifiers, which rights are required for different IMAP4
commands; how READ-WRITE/READ-ONLY response codes are related to ACL. commands; how READ-WRITE/READ-ONLY response codes are related to ACL.
3. Access Control 3. Access Control
The ACL extension is present in any IMAP4 implementation which The ACL extension is present in any IMAP4 implementation which
returns "ACL" as one of the supported capabilities to the CAPABILITY returns "ACL" as one of the supported capabilities to the CAPABILITY
command. command.
A server implementation conformant to this document MUST also return A server implementation conformant to this document MUST also return
rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability rights (see below) not defined in section 3.2 in the "RIGHTS="
response. capability.
An access control list is a set of <identifier,rights> pairs. An access control list is a set of <identifier,rights> pairs.
An ACL applies to a mailbox name. An ACL applies to a mailbox name.
Identifier is a UTF-8 [UTF-8] string. The identifier "anyone" is reserved Identifier is a UTF-8 [UTF-8] string. The identifier "anyone" is reserved
to refer to the universal identity (all authentications, including to refer to the universal identity (all authentications, including
anonymous). All user name strings accepted by the LOGIN or anonymous). All user name strings accepted by the LOGIN or
AUTHENTICATE commands to authenticate to the IMAP server are reserved AUTHENTICATE commands to authenticate to the IMAP server are reserved
as identifiers for the corresponding users. Identifiers starting with as identifiers for the corresponding users. Identifiers starting with
a dash ("-") are reserved for "negative rights", described below. a dash ("-") are reserved for "negative rights", described below.
skipping to change at line 104 skipping to change at line 105
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. Lowercase letters are reserved for "standard" rights, controlled. Lowercase letters are reserved for "standard" rights,
listed in section 3.1. (Note that for compatibility with deployed clients listed in section 3.1. (Note that for compatibility with deployed clients
and servers uppercase rights are not allowed). The set of and servers uppercase rights are not allowed). The set of
standard rights may only be extended by a standards-track document. standard rights may only be extended by a standards-track document.
Digits are reserved for implementation or site defined rights. Digits are reserved for implementation or site defined rights.
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 "swite" are in an implementation that uses UNIX mode bits, the rights "swite" 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 SETACL 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 name by using the LISTRIGHTS command. mailbox name by using the LISTRIGHTS command.
It is possible for multiple identifiers in an access control list to It is possible for multiple identifiers in an access control list to
skipping to change at line 140 skipping to change at line 141
This differs from DELETEACL in that a negative right is added to the This differs from DELETEACL in that a negative right is added to the
ACL, and is a part of the calculation of the rights. ACL, and is a part of the calculation of the rights.
Let's assume that an identifier "fred" refers to a user with login "fred". Let's assume that an identifier "fred" refers to a user with login "fred".
If the identifier "-fred" is granted the "w" right, If the identifier "-fred" is granted the "w" right,
that indicates that the "w" right is to be removed from users matching that indicates that the "w" right is to be removed from users matching
the identifier "fred", even though the user "fred" might have the identifier "fred", even though the user "fred" might have
the "w" right as a consequence of some other identifier in the ACL. the "w" right as a consequence of some other identifier in the ACL.
A DELETEACL of "fred" simply deletes the identifier "fred" A DELETEACL of "fred" simply deletes the identifier "fred"
from the ACL; it does not affect any rights that the user "fred" from the ACL; it does not affect any rights that the user "fred"
may get from another entry in the ACL. may get from another entry in the ACL, in particular it doesn't affect
rights granted to the identifier "-fred".
Server implementations are not required to support "negative right" Server implementations are not required to support "negative right"
identifiers. identifiers.
3.1. Standard rights 3.1. Standard rights
The currently defined standard rights are (note, that the list below The currently defined standard rights are (note that the list below
doesn't list all commands that use a particular right): doesn't list all commands that use a particular right):
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) r - read (SELECT the mailbox, perform STATUS)
s - keep seen/unseen information across sessions (set or clear \SEEN flag s - keep seen/unseen information across sessions (set or clear \SEEN flag
via STORE, APPEND or COPY) via STORE, APPEND or COPY)
w - write (set or clear flags other than \SEEN and \DELETED via STORE, w - write (set or clear flags other than \SEEN and \DELETED via STORE,
APPEND or COPY) APPEND or COPY)
i - insert (perform APPEND, COPY into mailbox) i - insert (perform APPEND, COPY into mailbox)
p - post (send mail to submission address for mailbox, p - post (send mail to submission address for mailbox,
skipping to change at line 184 skipping to change at line 186
and "x" rights, and the "delete" right as union of the "e" and "t" rights. and "x" rights, and the "delete" right as union of the "e" and "t" rights.
For the latter group, let's define the "create" rights as a synonym to the For the latter group, let's define the "create" rights as a synonym to the
"k" right, and the "delete" right as union of the "e", "t" and "x" rights. "k" right, and the "delete" right as union of the "e", "t" and "x" rights.
For compatibility with RFC 2086 this section defines two virtual rights For compatibility with RFC 2086 this section defines two virtual rights
"d" and "c". "d" and "c".
If a client includes the "d" right in a rights list, then it MUST be If a client includes the "d" right in a rights list, then it MUST be
treated as if the client had included every member of the "delete" right. treated as if the client had included every member of the "delete" right.
(It is not an error for a client to specify both the "d" right and (It is not an error for a client to specify both the "d" right and
one or more member of the "delete" right, but the effect is no different one or more members of the "delete" right, but the effect is no different
than if just the "d" right or all members of the "delete" right had been than if just the "d" right or all members of the "delete" right had been
specified). When all the "delete" member rights are set in a list of specified).
When any of the "delete" member rights is set in a list of
rights, the server MUST also include the "d" right when returning rights, the server MUST also include the "d" right when returning
the list in a MYRIGHTS or ACL response. the list in a MYRIGHTS or ACL response. This is so to enable older clients
If member of the "delete" right are not tied together, the "d" right conforming to RFC 2086 to work with newer servers. (*)
MUST NOT be returned in a LISTRIGHTS response.
Example: C: A001 SETACL INBOX.Drafts David lrswida
S: A001 OK Setacl complete
The client has specified the "d" right in the SETACL command above and it
expands to "et" on the server:
C: A002 GETACL INBOX.Drafts
S: * ACL INBOX Fred rwipslxetda David lrswideta
S: A002 OK Getacl complete
If the authentication identifier specified in the LISTRIGHTS command can be
granted any of the "delete" member rights to access a mailbox, then the server
MUST include the "d" right in the corresponding LISTRIGHTS response. (*)
If the member rights aren't tied to non-member rights, then the "d" right
is returned by itself in the LISTRIGHTS response. If any of the member rights
needs to be tied to one (or more) non-member right, then the "d" right and all
of the member rights need to be tied to the same non-member right(s) (**).
If a client includes the "c" right in a rights list, then it MUST be If a client includes the "c" right in a rights list, then it MUST be
treated as if the client had included every member of the "create" right. treated as if the client had included every member of the "create" right.
(It is not an error for a client to specify both the "c" right and (It is not an error for a client to specify both the "c" right and
one or more member of the "create" right, but the effect is no different one or more members of the "create" right, but the effect is no different
than if just the "c" right or all members of the "create" right had been than if just the "c" right or all members of the "create" right had been
specified). When all the "create" member rights are set in a list of specified).
When any of the "create" member rights is set in a list of
rights, the server MUST also include the "c" right when returning rights, the server MUST also include the "c" right when returning
the list in a MYRIGHTS or ACL response. the list in a MYRIGHTS or ACL response. This is so to enable older clients
If member of the "create" right are not tied together, the "c" right conforming to RFC 2086 to work with newer servers. (*)
MUST NOT be returned in a LISTRIGHTS response.
Example: C: A003 SETACL INBOX.Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 GETACL INBOX.Drafts
S: * ACL INBOX Fred rwipslxeta Byron lrswikcdeta
S: A002 OK Getacl complete
The client has specified the "d" right in the SETACL command above and it
expands to "et" on the server: As the client has specified the "k" right
(which is a member of the "c" right), the server also returns the "c" right.
If the authentication identifier specified in the LISTRIGHTS command can be
granted any of the "create" member rights to access a mailbox, then the server
MUST include the "c" right in the corresponding LISTRIGHTS response. (*)
If the member rights aren't tied to non-member rights, then the "c" right
is returned by itself in the LISTRIGHTS response. If any of the member rights
needs to be tied to one (or more) non-member right, then the "c" right and all
of the member rights need to be tied to the same non-member right(s) (**).
Example: The server that ties the rights as follows
lr s w i p k x t
and c=k
will return:
S: * LISTRIGHTS archive.imap anyone "" lr s w i p k x t c d
Example: The server that ties the rights as follows
lr s w i p k xte
and c=k
will return:
S: * LISTRIGHTS archive.imap anyone "" lr s w i p k xte c d
Example: The server that ties the rights as follows
lr s w i p k x te
and c=k
will return:
S: * LISTRIGHTS archive.imap anyone "" lr s w i p k c x te d
Example: The server that ties the rights as follows
lr swte i p k x
and c=kx
will return:
S: * LISTRIGHTS archive.imap anyone "" lr swted i p k x c
(*) Clients conforming to this document MUST ignore the virtual "d" and "c"
rights in MYRIGHTS, ACL and LISTRIGHTS responses.
(**) The IMAPEXT Working Group has debated this issue in great length
and after reviewing existing ACL implementations concluded that this is
a reasonable restriction.
3.2. Rights defined in RFC 2086.
For convenience, this section lists the rights which were defined in
the RFC 2086:
"l", "r", "s", "w", "i", "p", "a", "c", "d" and digit rights
("0" .. "9").
The listed rights MUST NOT be returned in the "RIGHTS=" capability
string.
4. Access control management commands and responses 4. Access control management commands and responses
Servers, when processing a command that have an authentication identifier Servers, when processing a command that have an authentication identifier
as a parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands), as a parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands),
SHOULD first prepare the received identifier using "SASLprep" profile SHOULD first prepare the received identifier using "SASLprep" profile
[SASLprep] of the "stringprep" algorithm [StringPrep]. If the [SASLprep] of the "stringprep" algorithm [StringPrep]. If the
preparation of the identifier fails or results in an empty string, the preparation of the identifier fails or results in an empty string, the
server MUST refuse to perform the command with a BAD response. server MUST refuse to perform the command with a BAD response.
skipping to change at line 237 skipping to change at line 334
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.
Note, that an unrecognized right MUST cause the command to return Note that an unrecognized right MUST cause the command to return
the BAD response. In particular, server MUST NOT silently ignore the BAD response. In particular, server MUST NOT silently ignore
unrecognized rights. unrecognized rights.
Example: C: A001 SETACL INBOX.Drafts Chris lrswicda Example: C: A001 SETACL INBOX.Drafts Chris lrswicda
S: A001 OK Setacl complete S: A001 OK Setacl complete
C: A035 SETACL INBOX.Drafts John lrQswicda C: A035 SETACL INBOX.Drafts John lrQswicda
S: A035 BAD Uppercase rights are not allowed S: A035 BAD Uppercase rights are not allowed
C: A036 SETACL INBOX.Drafts John lrqswicda C: A036 SETACL INBOX.Drafts John lrqswicda
skipping to change at line 265 skipping to change at line 362
Data: no specific data for this command Data: no specific data for this command
Result: OK - deleteacl completed Result: OK - deleteacl completed
NO - deleteacl failure: can't delete acl NO - deleteacl failure: can't delete acl
BAD - arguments invalid BAD - arguments invalid
The DELETEACL command removes any <identifier,rights> pair for the The DELETEACL command removes any <identifier,rights> pair for the
specified identifier from the access control list for the specified specified identifier from the access control list for the specified
mailbox. mailbox.
Example: C: B001 GETACL INBOX
S: * ACL INBOX Fred rwipslxeta -Fred wet $team w
S: B001 OK Getacl complete
C: B002 DELETEACL INBOX Fred
S: B002 OK Deleteacl complete
C: B003 GETACL INBOX
S: * ACL INBOX -Fred wet $team w
S: B003 OK Getacl complete
4.3. GETACL command 4.3. GETACL command
Arguments: mailbox name Arguments: mailbox name
Data: untagged responses: ACL Data: untagged responses: ACL
Result: OK - getacl completed Result: OK - getacl completed
NO - getacl failure: can't get acl NO - getacl failure: can't get acl
BAD - arguments invalid BAD - arguments invalid
skipping to change at line 286 skipping to change at line 392
an untagged ACL response. an untagged ACL response.
Some implementations may permit multiple forms of an authentication Some implementations may permit multiple forms of an authentication
identifier to reference the same IMAP account. Usually, such identifier to reference the same IMAP account. Usually, such
implementations will have a canonical form that is stored internally. implementations will have a canonical form that is stored internally.
An ACL response caused by an GETACL command may include a An ACL response caused by an GETACL command may include a
canonicalized form of the authentication identifier which might be canonicalized form of the authentication identifier which might be
different from the one used in the corresponding SETACL command. different from the one used in the corresponding SETACL command.
Example: C: A002 GETACL INBOX Example: C: A002 GETACL INBOX
S: * ACL INBOX Fred rwipslda S: * ACL INBOX Fred rwipsldexta
S: A002 OK Getacl complete S: A002 OK Getacl complete
4.4. LISTRIGHTS command 4.4. LISTRIGHTS command
Arguments: mailbox name Arguments: mailbox name
authentication identifier authentication identifier
Data: untagged responses: LISTRIGHTS Data: untagged responses: LISTRIGHTS
Result: OK - listrights completed Result: OK - listrights completed
skipping to change at line 313 skipping to change at line 419
Some implementations may permit multiple forms of an authentication Some implementations may permit multiple forms of an authentication
identifier to reference the same IMAP account. Usually, such identifier to reference the same IMAP account. Usually, such
implementations will have a canonical form that is stored internally. implementations will have a canonical form that is stored internally.
A LISTRIGHTS response caused by a LISTRIGHTS command MUST always A LISTRIGHTS response caused by a LISTRIGHTS command MUST always
return the same form of an authentication identifier as specified return the same form of an authentication identifier as specified
by the client. This is to allow the client to correlate the response by the client. This is to allow the client to correlate the response
with the command. with the command.
Example: C: a001 LISTRIGHTS ~/Mail/saved smith Example: C: a001 LISTRIGHTS ~/Mail/saved smith
S: * LISTRIGHTS ~/Mail/saved smith la r swicd S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte
S: a001 OK Listrights completed S: a001 OK Listrights completed
C: a005 LISTRIGHTS archive.imap anyone Example: C: a005 LISTRIGHTS archive.imap anyone
S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a S: * LISTRIGHTS archive.imap anyone "" l r s w i p k x t
0 1 2 3 4 5 6 7 8 9 e c d a 0 1 2 3 4 5 6 7 8 9
S: a005 Listrights successful S: a005 Listrights successful
4.5. MYRIGHTS command 4.5. MYRIGHTS command
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 - arguments invalid BAD - 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.
Example: C: A003 MYRIGHTS INBOX Example: C: A003 MYRIGHTS INBOX
S: * MYRIGHTS INBOX rwipslda S: * MYRIGHTS INBOX rwiptsldaex
S: A003 OK Myrights complete S: A003 OK Myrights complete
4.6. ACL response 4.6. ACL response
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 first The ACL response occurs as a result of a GETACL command. The first
string is the mailbox name for which this ACL applies. This is string is the mailbox name for which this ACL applies. This is
followed by zero or more pairs of strings, each pair contains the followed by zero or more pairs of strings, each pair contains the
identifier for which the entry applies followed by the set of identifier for which the entry applies followed by the set of
rights that the identifier has. rights that the identifier has.
Section 3.1.1 details additional server requirements related to handling
of the virtual "d" and "c" rights.
4.7. LISTRIGHTS response 4.7. LISTRIGHTS response
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 LISTRIGHTS response occurs as a result of a LISTRIGHTS
command. The first two strings are the mailbox name and identifier command. The first two strings are the mailbox name and identifier
for which this rights list applies. Following the identifier is a for which this rights list applies. Following the identifier is a
string containing the (possibly empty) set of rights the string containing the (possibly empty) set of rights the
identifier will always be granted in the mailbox. 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.
Section 3.1.1 details additional server requirements related to handling
of the virtual "d" and "c" rights.
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 LISTRIGHTS
command. command.
4.8. MYRIGHTS response 4.8. MYRIGHTS 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.
Section 3.1.1 details additional server requirements related to handling
of the virtual "d" and "c" rights.
5. Rights required to perform different IMAP4rev1 commands 5. Rights required to perform different IMAP4rev1 commands
Before executing a command an ACL compliant server must check which rights Before executing a command an ACL 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 they perform and list the rights required. It also gives the detailed
description of any special processing required. description of any special processing required.
For the purpose of this section the UID counterpart of a command is For the purpose of this section the UID counterpart of a command is
considered to be the same command, e.g. both UID COPY and COPY commands considered to be the same command, e.g. both UID COPY and COPY commands
require the same set of rights. require the same set of rights.
skipping to change at line 426 skipping to change at line 540
+ - The right is required + - The right is required
* - Only one of the rights marked with * is required (see description below) * - Only one of the rights marked with * is required (see description below)
? - The right is optional (see description below) ? - The right is optional (see description below)
"Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is
required required
"None" - No rights required to perform the command "None" - No rights required to perform the command
Listing and subscribing/unsubscribing mailboxes: Listing and subscribing/unsubscribing mailboxes:
LIST - "l" right is required. LIST - "l" right is required.
Note, that if the user has "l" right to a mailbox "A/B", but not to its parent 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, mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist,
for example: for example:
C: A777 LIST "" * C: A777 LIST "" *
S: * LIST (\NoInferiors) "/" "A/B" S: * LIST (\NoInferiors) "/" "A/B"
S: * LIST () "/" "C" S: * LIST () "/" "C"
S: * LIST (\NoInferiors) "/" "C/D" S: * LIST (\NoInferiors) "/" "C/D"
S: A777 OK LIST completed S: A777 OK LIST completed
SUBSCRIBE - "l" right is required only if the server checks for mailbox existence SUBSCRIBE - "l" right is required only if the server checks for mailbox existence
when performing SUBSCRIBE. when performing SUBSCRIBE.
skipping to change at line 448 skipping to change at line 562
UNSUBSCRIBE - no rights required to perform this operation. UNSUBSCRIBE - no rights required to perform this operation.
LSUB - "l" right is required only if the server checks for mailbox existence when LSUB - "l" right is required only if the server checks for mailbox existence when
performing SUBSCRIBE. performing SUBSCRIBE.
Mailbox management: Mailbox management:
CREATE - "k" right on a nearest existing parent mailbox. When a new CREATE - "k" right on a nearest existing parent mailbox. When a new
mailbox is created it SHOULD inherit the ACL from the parent mailbox is created it SHOULD inherit the ACL from the parent
mailbox (if one exists) in the defined hierarchy. mailbox (if one exists) in the defined hierarchy.
DELETE - "x" right on the mailbox. Note, that some servers don't allow 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 to delete a non-empty mailbox. If this is the case, the user
also need both "e" and "t" rights, in order to make the mailbox would also need "r", "e" and "t" rights, in order to open the
empty first. mailbox and empty it.
The DELETE command MUST delete the ACL associated with the The DELETE command MUST delete the ACL associated with the
deleted mailbox. deleted mailbox.
RENAME - Moving a mailbox from one parent to another requires the "x" right 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. on the mailbox itself and the "k" right for the new parent.
For example, if the user wants to rename mailbox named "A/B/C" to For example, if the user wants to rename mailbox named "A/B/C" to
"D/E", the user must have the "x" right for the mailbox "A/B/C" "D/E", the user must have the "x" right for the mailbox "A/B/C"
and the "k" right for the mailbox "D". and the "k" right for the mailbox "D".
skipping to change at line 562 skipping to change at line 676
LISTRIGHTS - "a" right on the mailbox. LISTRIGHTS - "a" right on the mailbox.
6. Other considerations 6. Other considerations
6.1. Additional requirements and Implementation notes 6.1. Additional requirements and Implementation notes
6.1.1. Servers 6.1.1. Servers
This document defines an additional capability that is used to announce This document defines an additional capability that is used to announce
the list of extra rights (excluding the ones defined in the RFC 2086) the list of extra rights (excluding the ones defined in the RFC 2086)
supported by the server. The set of rights MUST include "t", "e", "x" and "k". supported by the server. The set of rights MUST include "t", "e", "x"
Note, that the extra rights can appear in any order. and "k". Note that the extra rights can appear in any order.
Example: C: 1 capability Example: C: 1 capability
S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ ACL RIGHTS=texk S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ ACL RIGHTS=texk
S: 1 OK completed S: 1 OK completed
Any server implementing an ACL extension MUST accurately reflect the current Any server implementing an ACL extension MUST accurately reflect the current
user's rights in FLAGS and PERMANENTFLAGS responses. user's rights in FLAGS and PERMANENTFLAGS responses.
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 (\Seen \Answered \Flagged \*)] Limited S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed S: A142 OK [READ-WRITE] SELECT completed
C: A143 MYRIGHTS INBOX C: A143 MYRIGHTS INBOX
S: * MYRIGHTS INBOX rwis 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 \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
S: * MYRIGHTS INBOX lrwis
S: A143 OK completed S: A143 OK completed
Servers MAY cache the rights a user has on a mailbox when the mailbox 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 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, SETACL or DELETEACL, commands specific to the selected state (e.g., STORE,
EXPUNGE) might not reflect the changed rights until the mailbox is 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 re-selected. If the server checks the rights on each command, then it SHOULD
send FLAGS and PERMANENTFLAGS responses if they have changed. send FLAGS and PERMANENTFLAGS responses if they have changed.
An ACL server MAY modify one or more ACL for one or more identifier as a An ACL server MAY modify one or more ACL for one or more identifier as a
skipping to change at line 621 skipping to change at line 751
to allow access by multiple users. Let's denote a "shared multiuser to allow access by multiple users. Let's denote a "shared multiuser
write access" as a "shared multiuser access" when a user may be write access" as a "shared multiuser access" when a user may be
granted flag modification rights (any of "w", "s" or "t"). granted flag modification rights (any of "w", "s" or "t").
Section 5 describes which rights are required for modifying different flags. Section 5 describes which rights are required for modifying different flags.
If the ACL server implements some flags as shared for a mailbox (i.e., 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 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 visible to another user), let's call the set of rights associated with these
flags (as described in Section 5) for that mailbox collectively as flags (as described in Section 5) for that mailbox collectively as
"shared flag rights". Note, that "shared flag rights" set MAY be different "shared flag rights". Note that "shared flag rights" set MAY be different
for different mailboxes. for different mailboxes.
If the server doesn't support "shared multiuser write access" to a If the server doesn't support "shared multiuser write access" to a
mailbox or doesn't implement shared flags on the mailbox, "shared flag mailbox or doesn't implement shared flags on the mailbox, "shared flag
rights" for the mailbox is defined to be the empty set. rights" for the mailbox is defined to be the empty set.
Example 1: Mailbox "banan" allows "shared multiuser write access" and Example 1: Mailbox "banan" allows "shared multiuser write access" and
implements flags \Deleted, \Answered and $MDNSent as implements flags \Deleted, \Answered and $MDNSent as
shared flags. "Shared flag rights" for the mailbox "banan" shared flags. "Shared flag rights" for the mailbox "banan"
is a set containing flags "t" (because system flag \Deleted is a set containing flags "t" (because system flag \Deleted
skipping to change at line 720 skipping to change at line 850
SP rights *(SP rights) SP rights *(SP rights)
mod_rights = astring mod_rights = astring
;; +rights to add, -rights to remove ;; +rights to add, -rights to remove
;; rights to replace ;; rights to replace
myrights = "MYRIGHTS" SP mailbox myrights = "MYRIGHTS" SP mailbox
myrights_data = "MYRIGHTS" SP mailbox SP rights myrights_data = "MYRIGHTS" SP mailbox SP rights
new_rights = 1*(LOWER_ALPHA / DIGIT) new_rights = 1*LOWER_ALPHA
;; MUST include "t", "e", "x" and "k" ;; MUST include "t", "e", "x" and "k".
;; MUST NOT include standard rights listed
;; in section 3.2
rights = astring rights = astring
;; only lowercase ASCII letters and digits ;; only lowercase ASCII letters and digits
;; are allowed. ;; are allowed.
rights_capa = "RIGHTS=" new_rights rights_capa = "RIGHTS=" new_rights
;; RIGHTS=... capability ;; RIGHTS=... capability
setacl = "SETACL" SP mailbox SP identifier setacl = "SETACL" SP mailbox SP identifier
SP mod_rights SP mod_rights
9. IANA Considerations 9. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located IESG approved experimental RFC. The registry is currently located
at: at:
http://www.iana.org/assignments/imap4-capabilities http://www.iana.org/assignments/imap4-capabilities
skipping to change at line 809 skipping to change at line 942
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
14. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
skipping to change at line 854 skipping to change at line 987
FETCH, as this is required for SELECT/EXAMINE to be successful. FETCH, as this is required for SELECT/EXAMINE to be successful.
8. LISTRIGHTS requires the "a" right on the mailbox (same as SETACL). 8. LISTRIGHTS requires the "a" right on the mailbox (same as SETACL).
9. Deleted "PARTIAL", this is a deprecated feature of RFC 1730. 9. Deleted "PARTIAL", this is a deprecated feature of RFC 1730.
10. Specified that the "w" right controls setting flags other than \Seen 10. Specified that the "w" right controls setting flags other than \Seen
and \Deleted on APPEND. Also specified that the "s" right controls and \Deleted on APPEND. Also specified that the "s" right controls
the \Seen flag and that the "t" right controls the \Deleted flag. the \Seen flag and that the "t" right controls the \Deleted flag.
11. SUBSCRIBE is NOT allowed with the "r" right. 11. Specified that SUBSCRIBE is NOT allowed with the "r" right.
12. Specified that the "l" right controls SUBSCRIBE. 12. Specified that the "l" right controls SUBSCRIBE.
13. GETACL is NOT allowed with the "r" right, even though there are 13. GETACL is NOT allowed with the "r" right, even though there are
several implementations that allows that. If a user only has "r" several implementations that allows that. If a user only has "r"
right, GETACL can disclose information about identifiers existing right, GETACL can disclose information about identifiers existing
on the mail system. on the mail system.
14. Clarified that RENAME requires the "k" right for the new parent and 14. Clarified that RENAME requires the "k" right for the new parent and
the "x" right for the old name. the "x" right for the old name.
skipping to change at line 885 skipping to change at line 1018
19. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY 19. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY
response codes. response codes.
20. Changed BNF to ABNF. 20. Changed BNF to ABNF.
21. Added "Implementation Notes" section. 21. Added "Implementation Notes" section.
22. Updated "References" section. 22. Updated "References" section.
23. Added more examples.
24. Clarified when the virtual "c" and "d" rights are returned in ACL,
MYRIGHTS and LISTRIGHTS responses.
Appendix B. Compatibility with RFC 2086 Appendix B. Compatibility with RFC 2086
This section gives guidelines how an existing RFC 2086 server This section gives guidelines how an existing RFC 2086 server
implementation may be updated to comply with this document. implementation may be updated to comply with this document.
This document splits the "d" right into several new different rights: "t", This document splits the "d" right into several new different rights:
"e" and possibly "x" (see section 3.1.1 for more details). The "d" right "t", "e" and possibly "x" (see section 3.1.1 for more details). The "d"
remains for backwards-compatibility but it is a virtual right. The server right remains for backwards-compatibility but it is a virtual right.
should implement one of the following two approaches to handle the "d" right The server should implement one of the following two approaches to
and the new rights that have replaced it. handle the "d" right and the new rights that have replaced it.
a). "t", "e" (and possibly "x) together - almost no changes. a). "t", "e" (and possibly "x) together - almost no changes.
b). Implement separate "x", "t" and "e". Return the "d" right in a b). Implement separate "x", "t" and "e". Return the "d" right in a
MYRIGHTS response or an ACL response containing ACL MYRIGHTS response or an ACL response containing ACL
information when all of the "t", "e" (and "x") are granted. information when any of the "t", "e" (and "x") is granted.
In a similar manner this document splits the "c" right into several new In a similar manner this document splits the "c" right into several
different rights: "k" and possibly "x" (see section 3.1.1 for more details). new different rights: "k" and possibly "x" (see section 3.1.1 for more
The "c" right remains for backwards-compatibility but it is a virtual right. details). The "c" right remains for backwards-compatibility but it is
The server should implement one of the two approaches described above. a virtual right. The server should implement one of the two approaches
described above.
Also check Sections 6.1 and 6.2, as well as the appendix A to see Also check Sections 6.1 and 6.2, as well as the appendix A to see
other changes required. Server implementors should check which rights other changes required. Server implementors should check which rights
are required to invoke different IMAP4 commands as described in are required to invoke different IMAP4 commands as described in
Section 5. Section 5.
Appendix C. Known deficiencies Appendix C. Known deficiencies
This specification has some known deficiencies including: This specification has some known deficiencies including:
1. This is inadequate to provide complete read-write access to mailboxes 1. This is inadequate to provide complete read-write access to
protected by Unix-style rights bits because there is no equivalent to mailboxes protected by Unix-style rights bits because there is no
"chown" and "chgrp" commands nor is there a good way to discover such equivalent to "chown" and "chgrp" commands nor is there a good way
limitations are present. to discover such limitations are present.
2. Because this extension leaves the specific semantics of how rights are 2. Because this extension leaves the specific semantics of how rights
combined by the server and which rights are tied as implementation are combined by the server as implementation defined, the ability
defined, the ability to build a user-friendly interface is limited. to build a user-friendly interface is limited.
The work-in-progress "ACL2" extension is intended to redesign this The work-in-progress "ACL2" extension is intended to redesign this
extension to address these deficiencies without the constraint of extension to address these deficiencies without the constraint of
backwards-compatibility and may eventually supercede this facility. backwards-compatibility and may eventually supercede this facility.
However, RFC 2086 is deployed in multiple implementations so this However, RFC 2086 is deployed in multiple implementations so this
intermediate step which fixes the straightforward deficiencies in a intermediate step which fixes the straightforward deficiencies in a
backwards compatible fashion is considered worthwhile. backwards compatible fashion is considered worthwhile.
Appendix D. Acknowledgment Appendix D. Acknowledgment
 End of changes. 

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