draft-ietf-imapext-acl-02.txt   draft-ietf-imapext-acl-03.txt 
IMAPEXT Working Group A. Melnikov IMAPEXT Working Group A. Melnikov
Internet Draft Editor Internet Draft Editor
Document: draft-ietf-imapext-acl-02.txt February 2002 Document: draft-ietf-imapext-acl-03.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 60 skipping to change at line 60
$xxxxx reserved for future definition $xxxxx reserved for future definition
Non-definable identifiers. Server implementations SHOULD support $WORLD, Non-definable identifiers. Server implementations SHOULD support $WORLD,
and MUST support anyone and user names. However, a server can respond and MUST support anyone and user names. However, a server can respond
with a NO. with a NO.
$WORLD all authorized users but not anonymous $WORLD all authorized users but not anonymous
$ANONYMOUS anonymous users $ANONYMOUS anonymous users
$DISABLE disabled rights $DISABLE disabled rights
2). Should the document define additional capabilities for servers that 2). Do we need a mechanism to encode login names if they start with
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 3). Should the annotations (ANNOTATE) be controlled by "w" right?
$, dash?
4). Should the "l" right control UNSUBSCRIBE or should a client be able to
unsubscribe a mailbox even if the client can't LIST it?
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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. 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
skipping to change at line 104 skipping to change at line 108
groups and implementation defined aliases. All other identifier strings groups and implementation defined aliases. All other identifier strings
are interpreted in an 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, SUBSCRIBE/UNSUBSCRIBE
r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, mailbox)
r - read (SELECT the mailbox, perform STATUS, 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 (set or clear \SEEN flag
w - write (STORE flags other than \SEEN and \DELETED) via STORE or APPEND)
w - write (set or clear flags other than \SEEN and \DELETED via STORE
or APPEND)
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)
t - delete messages (STORE \DELETED flag) t - delete messages (set or clear \DELETED flag via STORE or APPEND)
e - perform EXPUNGE e - perform EXPUNGE
d - if a client sets "d" right, the server MUST set "x", "e" and "t" 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 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" 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 are set, the server MUST return "d" right in response to a GETACL
command. This right is defined for backward compatibility with ACL command. This right is defined for backward compatibility with ACL
extension (RFC 2086). extension (RFC 2086).
a - administer (perform SETACL) a - administer (perform SETACL and DELETEACL)
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,
in an implementation that uses unix mode bits, the rights "wisd" are in an implementation that uses unix mode bits, the rights "wisd" are
skipping to change at line 324 skipping to change at line 331
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.
6. Formal Syntax 6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
Form (BNF) notation as specified in [RFC-822] 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) acl_data = "ACL" SPACE mailbox *(SPACE identifier SPACE rights)
deleteacl ::= "DELETEACL" SPACE mailbox SPACE identifier deleteacl = "DELETEACL" SPACE mailbox SPACE identifier
getacl ::= "GETACL" SPACE mailbox getacl = "GETACL" SPACE mailbox
identifier ::= astring identifier = astring
;; 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
myrights ::= "MYRIGHTS" SPACE mailbox myrights = "MYRIGHTS" SPACE mailbox
myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE rights myrights_data = "MYRIGHTS" SPACE mailbox SPACE rights
rights ::= astring resp-text-code =/ myrights_data
setacl ::= "SETACL" SPACE mailbox SPACE identifier SPACE mod_rights rights = astring
setacl = "SETACL" 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 423 skipping to change at line 431
Negative rights allowed: No. Negative rights allowed: No.
Groups allowed: Yes, but not required. Groups allowed: Yes, but not required.
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. References 9. Security Considerations
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
RFC 1730, University of Washington, December 1994.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646",
RFC 2279.
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.
11. Aknowledgement 10. Other considerations
10.1. Compatibility with RFC 2086
Any server that prohibits a user name in LOGIN/AUTHENTICATE that starts
with "$" MUST report "ACL" capability in addition to a "ACL=..." capability.
10.2. Implementation notes
Any server implementing an ACL2 extension MUST accurately reflect the current
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
or EXAMINE command.
11. References
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
November 1997.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, University of Washington, December 1996.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646",
RFC 2279.
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 also appreciate comments received from Mark Crispin, Chris Newman,
Curtis King, Lyndon Nerenberg and other members of IMAPEXT working group. Cyrus Daboo, Curtis King, Lyndon Nerenberg and other members of IMAPEXT
working group.
12. 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
#900 10117 - Jasper Ave. #900 10117 - Jasper Ave.
Edmonton, Alberta, T5J 1W8, CANADA Edmonton, Alberta, T5J 1W8, CANADA
13. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society 2002. All Rights Reserved. Copyright (C) The Internet Society 2002. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at line 507 skipping to change at line 534
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.
6. Added "t" right that controls STORE \Deleted. Redefined "d" to be a 6. Added "t" right that controls STORE \Deleted. Redefined "d" to be a
macro for "e", "x" and "t". macro for "e", "x" and "t".
7. Added "ACL2=UNION" and "ACL2=MOST-SPECIFIC" capabilities and IANA 7. Added "ACL2=UNION" and "ACL2=MOST-SPECIFIC" capabilities and IANA
registration template. registration template.
8. Specified that "a" right also controls DELETEACL
9. Specified that "r" right also controls STATUS
10. Specified that "w" controls setting flags other than \Seen and \Deleted
on APPEND. Same for "s" and "t" flags.
11. Specified that "l" controls SUBSCRIBE/UNSUBSCRIBE.
12. Added note about compatibility with RFC 2086
13. Added "Implementation Notes" section.
14. Updated "References" section.
 End of changes. 

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