draft-ietf-imapext-acl-01.txt   draft-ietf-imapext-acl-02.txt 
IMAPEXT Working Group A. Melnikov IMAPEXT Working Group A. Melnikov
Internet Draft Editor Internet Draft Editor
Document: draft-ietf-imapext-acl-01.txt November 2001 Document: draft-ietf-imapext-acl-02.txt February 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 68 skipping to change at line 68
$DISABLE disabled rights $DISABLE disabled rights
2). Should the document define additional capabilities for servers that 2). Should the document define additional capabilities for servers that
implement "union of positive rights minus union of negative rigths"? implement "union of positive rights minus union of negative rigths"?
Or maybe add capability for implementations that use the most specific Or maybe add capability for implementations that use the most specific
rights? rights?
3). Do we need a mechanism to encode login names if they start with 3). Do we need a mechanism to encode login names if they start with
$, dash? $, 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
server respectively. server respectively.
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 "ACL" as one of the supported capabilities to the CAPABILITY returns a capability starting with "ACL2=" as one of the supported
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. 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
skipping to change at line 120 skipping to change at line 118
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 mailboxes (CREATE new sub-mailboxes in any c - create mailboxes (CREATE new sub-mailboxes in any
implementation-defined hierarchy, parent mailbox for the new implementation-defined hierarchy, parent mailbox for the new
mailbox name in RENAME). mailbox name in RENAME).
When a new mailbox is created it SHOULD inherit rights from When a new mailbox is created it SHOULD inherit rights from
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)
d - delete messages (STORE \DELETED flag) t - delete messages (STORE \DELETED flag)
e - perform EXPUNGE e - perform EXPUNGE
d - if a client sets "d" right, the server MUST 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", "e" and "t"
are set, the server MUST return "d" right in response to a GETACL
command. This right is defined for backward compatibility with ACL
extension (RFC 2086).
a - administer (perform SETACL) a - administer (perform SETACL)
Note, that moving (RENAME command) mailbox from one parent to another 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. 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" 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 ("/" is hierarchy separator) to "D/E", the user must have "x" right
for mailbox "A/B/C" and "c" right for mailbox "D". 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,
skipping to change at line 148 skipping to change at line 152
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 LISTRIGHTS 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". For
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 "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. An implementation may choose, for access is implementation-defined. The set of rules that describes
example, to use the union of the rights granted to the applicable how access is calculated is defined by a rule identifier (rule-ID).
identifiers minus the union of the negative rights applying
to the applicable identifiers. An implementation may instead choose, A client may determine the set of rights granted to the logged-in user
for example, to only use those rights granted to the most specific for a given mailbox by using the MYRIGHTS command.
identifier present in the ACL. A client may determine the set of rights
granted to the logged-in user for a given mailbox by using the MYRIGHTS If a server implementing ACL2 uses the union of the rights granted to
command. the applicable identifiers minus the union of the negative rights
in order to calculate access, it MUST report "ACL2=UNION" in the server's
capability list.
An implementation may instead choose to only use those rights granted
to the most specific identifier present in the ACL. In this case the
server MUST report "ACL2=MOST-SPECIFIC" in the server's capability
list.
If the server implements any other policy for rights calculation,
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.
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 line 221 skipping to change at line 236
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 rwipslexda S: * ACL INBOX Fred rwipslextda
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 swi cdex S: * LISTRIGHTS ~/Mail/saved smith la r swi cdext
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 e x S: * LISTRIGHTS 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 Listrights completed
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
skipping to change at line 344 skipping to change at line 359
;; +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
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. IANA considerations
7.1. ACL access calculation rule Registration Template
When an access calculation rule for ACL2 extension is registered, the
following information is supplied:
Rule Identification: specify a string that identifies this
rule. Unless the rule is registered with the IANA, the
rule's identification must start with "X-".
The server supporting a particular rule <rule-ID> MUST report
"ACL2=<rule-ID>" in the capability list.
Rule Semantics: specify how access rights for a mailbox are calculated.
Negative rights allowed: specify whether "negative right" identifiers are
allowed.
Groups allowed: specify whether group identifiers are allowed.
Special Identifiers: describe whether any implementation defined
aliases are allowed and define their meaning.
Contact Information: specify the postal and electronic contact
information for the author of the feature.
8. Initial Registrations
8.1. Registration: UNION access calculation rule
Rule Identification: UNION
Rule Semantics: the union of the rights granted to
the applicable identifiers minus the union of the negative rights.
Negative rights allowed: Yes.
Groups allowed: Yes, but not required.
Special Identifiers: No.
Contact Information: c.f., the "Editor's Address" section of this
memo
8.2. Registration: MOST-SPECIFIC access calculation rule
Rule Identification: MOST-SPECIFIC
Rule Semantics: the rights granted to the most specific identifier
present in the ACL are used, i.e. if the user identifier is present,
its ACL is used. If no user identifier is present, but a group that
includes this user as a member is present, the group ACL is used.
If neither user, nor group identifier is present, but an ACL for
a special group "anyone" is present, the ACL for "anyone" is used.
Negative rights allowed: No.
Groups allowed: Yes, but not required.
Special Identifiers: No.
Contact Information: c.f., the "Editor's Address" section of this
memo
9. 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 IS0 10646", [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646",
RFC 2279. RFC 2279.
8. Security Considerations 10. 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. Aknowledgement 11. 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 also appreciate comments received from Mark Crispin, Chris Newman,
Curtis King, Lyndon Nerenberg and other members of IMAPEXT working group. Curtis King, Lyndon Nerenberg and other members of IMAPEXT working group.
10. Editor's Address 12. Editor's Address
Alexey Melnikov Alexey Melnikov
mailto: Alexey.Melnikov@messagingdirect.com mailto: mel@messagingdirect.com
ACI WorldWide/MessagingDirect ACI WorldWide/MessagingDirect
900 10117 - Jasper Ave. #900 10117 - Jasper Ave.
Edmonton, Alberta, T5J 1W8, CANADA Edmonton, Alberta, T5J 1W8, CANADA
13. Full Copyright Statement
Copyright (C) The Internet Society 2002. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
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. Specified that identifiers starting with a dollar sign ("$") 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
are not backward compatible with ACL RFC.
6. Added "t" right that controls STORE \Deleted. Redefined "d" to be a
macro for "e", "x" and "t".
7. Added "ACL2=UNION" and "ACL2=MOST-SPECIFIC" capabilities and IANA
registration template.
 End of changes. 

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