draft-ietf-imapext-acl-00.txt   draft-ietf-imapext-acl-01.txt 
IMAPEXT Working Group A. Melnikov
Network Working Group J. Myers Internet Draft Editor
Internet Draft Netscape Communications Document: draft-ietf-imapext-acl-01.txt November 2001
Document: draft-ietf-imapext-acl-00.txt May 2000
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 page 2, line ? skipping to change at line 35
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au. munnari.oz.au.
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.
Internet DRAFT ACL May 23, 2000 0. Open issues
This section will be removed when the draft will be published as RFC.
It is intended to simplify discussion.
1). Should the document define exact syntax for identifiers starting
with '$'? For example, the following was proposed by Mark Crispin:
Definable identifiers. Server implementations are *NOT* required to
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
$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,
and MUST support anyone and user names. However, a server can respond
with a NO.
$WORLD all authorized users but not anonymous
$ANONYMOUS anonymous users
$DISABLE disabled rights
2). Should the document define additional capabilities for servers that
implement "union of positive rights minus union of negative rigths"?
Or maybe add capability for implementations that use the most specific
rights?
3). Do we need a mechanism to encode login names if they start with
$, dash?
4). Drop identifiers starting with dash?
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 page 2, line ? skipping to change at line 96
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. The identifier "anyone" is reserved to Identifier is a UTF-8 string. The identifier "anyone" is reserved to
refer to the universal identity (all authentications, including 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 user. Identifiers starting with as identifiers for the corresponding user. Identifiers starting with
a dash ("-") are reserved for "negative rights", described below. a dash ("-") are reserved for "negative rights", described below.
Identifiers starting with a dollar sign ("$") are reserved for Identifiers starting with a dollar sign ("$") are reserved for
groups. All other identifier strings are interpreted in an groups and implementation defined aliases. All other identifier strings
implementation-defined manner. 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) l - lookup (mailbox is visible to LIST/LSUB commands)
r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL,
SEARCH, COPY from mailbox) SEARCH, COPY from mailbox)
s - keep seen/unseen information across sessions (STORE \SEEN flag) s - keep seen/unseen information across sessions (STORE \SEEN flag)
w - write (STORE flags other than \SEEN and \DELETED) w - write (STORE flags other than \SEEN and \DELETED)
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,
not enforced by IMAP4 itself) not enforced by IMAP4 itself)
c - create and delete mailbox (CREATE new sub-mailboxes in any c - create mailboxes (CREATE new sub-mailboxes in any
implementation-defined hierarchy, RENAME or DELETE mailbox) implementation-defined hierarchy, parent mailbox for the new
d - delete messages (STORE \DELETED flag, perform EXPUNGE) mailbox name in RENAME).
When a new mailbox is created it SHOULD inherit rights from
the parent mailbox (if one exists) in the defined hierarchy.
x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
d - delete messages (STORE \DELETED flag)
e - perform EXPUNGE
a - administer (perform SETACL) a - administer (perform SETACL)
Internet DRAFT ACL May 23, 2000 Note, that moving (RENAME command) mailbox from one parent to another
requires "x" right on the mailbox itself and "c" right for the new parent.
For example, if the user wants to rename mailbox named "A/B/C"
("/" is hierarchy separator) to "D/E", the user must have "x" right
for mailbox "A/B/C" and "c" right for mailbox "D".
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 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
skipping to change at page 3, line 32 skipping to change at line 155
example, if the identifier "-fred" is granted the "w" right, that example, if the identifier "-fred" is granted the "w" right, that
indicates that the "w" right is to be removed from users matching the indicates that the "w" right is to be removed from users matching the
identifier "fred". Server implementations are not required to identifier "fred". Server implementations are not required to
support having identifiers which start with a dash in ACLs. support having identifiers which start with a dash in ACLs.
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". These rights are combined by taking the union of the "anyone". How these rights are combined to determine the user's
rights granted to the applicable identifiers and then removing the access is implementation-defined. An implementation may choose, for
union of the negative rights applying to the applicable identifiers. example, to use the union of the rights granted to the applicable
identifiers minus the union of the negative rights applying
A client may determine the set of rights granted to the logged-in to the applicable identifiers. An implementation may instead choose,
user for a given mailbox by using the MYRIGHTS command. for example, to only use those rights granted to the most specific
identifier present in the ACL. A client may determine the set of rights
Internet DRAFT ACL May 23, 2000 granted to the logged-in user for a given mailbox by using the MYRIGHTS
command.
4. Commands 4. Commands
4.1. SETACL 4.1. SETACL
Arguments: mailbox name Arguments: mailbox name
authentication identifier authentication identifier
access right modification access right modification
Data: no specific data for this command Data: no specific data for this command
skipping to change at page 5, line 5 skipping to change at line 207
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 - command unknown or arguments invalid BAD - command unknown or 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 identifier from the access control list for the
specified mailbox. specified mailbox.
Internet DRAFT ACL May 23, 2000
4.3. GETACL 4.3. GETACL
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 - command unknown or arguments invalid BAD - command unknown or arguments invalid
The GETACL command returns the access control list for mailbox in The GETACL command returns the access control list for mailbox in
an untagged ACL reply. an untagged ACL reply.
Example: C: A002 GETACL INBOX Example: C: A002 GETACL INBOX
S: * ACL INBOX Fred rwipslda S: * ACL INBOX Fred rwipslexda
S: A002 OK Getacl complete S: A002 OK Getacl complete
4.4. LISTRIGHTS 4.4. LISTRIGHTS
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
NO - listrights failure: can't get rights list NO - listrights 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 LISTRIGHTS 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 LISTRIGHTS ~/Mail/saved smith
S: * LISTRIGHTS ~/Mail/saved smith la r swicd S: * LISTRIGHTS ~/Mail/saved smith la r swi cdex
S: a001 OK Listrights completed S: a001 OK Listrights completed
C: a005 LISTRIGHTS archive.imap anyone 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 c d a e x
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 Listrights completed
Internet DRAFT ACL May 23, 2000
4.5. MYRIGHTS 4.5. 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.
Example: C: A003 MYRIGHTS INBOX Example: C: A003 MYRIGHTS INBOX
S: * MYRIGHTS INBOX rwipslda S: * MYRIGHTS INBOX rwipsldexa
S: A003 OK Myrights complete S: A003 OK Myrights complete
5. Responses 5. Responses
5.1. ACL 5.1. ACL
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 ACL response occurs as a result of a GETACL command. The
skipping to change at page 7, line 4 skipping to change at line 290
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 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.
Internet DRAFT ACL May 23, 2000
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 LISTRIGHTS
command. command.
5.3. MYRIGHTS 5.3. MYRIGHTS
skipping to change at page 8, line 5 skipping to change at line 336
;; UTF-8 ;; UTF-8
listrights ::= "LISTRIGHTS" SPACE mailbox SPACE identifier listrights ::= "LISTRIGHTS" SPACE mailbox SPACE identifier
listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier
SPACE rights *(SPACE rights) SPACE rights *(SPACE rights)
mod_rights ::= astring mod_rights ::= astring
;; +rights to add, -rights to remove ;; +rights to add, -rights to remove
Internet DRAFT ACL May 23, 2000
;; rights to replace
myrights ::= "MYRIGHTS" SPACE mailbox myrights ::= "MYRIGHTS" SPACE mailbox
myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE rights myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE rights
rights ::= astring rights ::= astring
setacl ::= "SETACL" SPACE mailbox SPACE identifier SPACE mod_rights setacl ::= "SETACL" SPACE mailbox SPACE identifier SPACE mod_rights
7. References 7. References
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
RFC 1730, University of Washington, December 1994. RFC 1730, University of Washington, December 1994.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822. Messages", STD 11, RFC 822.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISP 10646", [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646",
RFC 2279. RFC 2279.
8. Security Considerations 8. 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 GETACL 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.
9. Author's Address 9. Aknowledgement
John G. Myers
Carnegie-Mellon University
5000 Forbes Ave.
Pittsburgh PA, 15213-3890
Email: jgm+@cmu.edu This document is a revision of the RFC 2086 written by John G. Myers.
Appendix A. Changes since RFC 2086 Editor also appreciate comments received from Mark Crispin, Chris Newman,
Curtis King, Lyndon Nerenberg and other members of IMAPEXT working group.
1. Changed the charset of "identifier" from US-ASCII to UTF-8 10. Editor's Address
2. Specified that identifiers starting with a dollar sign ("$") are Alexey Melnikov
reserved for groups mailto: Alexey.Melnikov@messagingdirect.com
3. Specified that mailbox deletion is controled by the "c" right. ACI WorldWide/MessagingDirect
900 10117 - Jasper Ave.
Edmonton, Alberta, T5J 1W8, CANADA
Internet DRAFT ACL May 23, 2000 Appendix A. Changes since RFC 2086
4. Required servers to implement "union of rights minus union of 1. Changed the charset of "identifier" from US-ASCII to UTF-8.
negative rights" for evaluating ACLs.
Internet DRAFT ACL May 23, 2000 2. Specified that identifiers starting with a dollar sign ("$") are
reserved for groups and implementation defined aliases.
TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss 3. Specified that mailbox deletion is controled by the "x" right and
EXPUNGE is controlled by "e" right.
Status of this Memo ............................................... i 4. Clarified that RENAME requires "c" right for the new parent and "x"
1. Abstract ..................................................... 2 right for the old name.
2. Conventions Used in this Document ............................ 2
3. Introduction and Overview .................................... 2
4. Commands ..................................................... 4
4.1. SETACL ....................................................... 4
4.2. DELETEACL .................................................... 4
4.3. GETACL ....................................................... 4
4.4. LISTRIGHTS ................................................... 5
4.5. MYRIGHTS ..................................................... 5
5. Responses .................................................... 6
5.1. ACL .......................................................... 6
5.2. LISTRIGHTS ................................................... 6
5.3. MYRIGHTS ..................................................... 7
6. Formal Syntax ................................................ 7
7. References ................................................... 8
8. Security Considerations ...................................... 8
9. Author's Address ............................................. 8
Appendix A. Changes since RFC 2086 ................................ 8
 End of changes. 

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