draft-ietf-imapext-acl-08.txt   draft-ietf-imapext-acl-09.txt 
IMAPEXT Working Group A. Melnikov IMAPEXT Working Group A. Melnikov
Internet Draft Editor Internet Draft Editor
Document: draft-ietf-imapext-acl-08.txt June 2003 Document: draft-ietf-imapext-acl-09.txt August 2003
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 41 skipping to change at line 41
editor as a Proposed Standard for the Internet Community. Discussion editor as a Proposed Standard for the Internet Community. Discussion
and suggestions for improvement are requested. Distribution of this and suggestions for improvement are requested. Distribution of this
draft is unlimited. draft is unlimited.
0. Open issues and ToDo list 0. Open issues and ToDo list
This section will be removed when the draft will be published as RFC. This section will be removed when the draft will be published as RFC.
It is intended to simplify discussion. It is intended to simplify discussion.
1). Require support for special identifier "disabled" for 1). Require support for special identifier "disabled" for
"ACL2=MOST-SPECIFIC" model? "ACL2=MOST-SPECIFIC" model? Can the same result be achieved with
<identifier, "">?
2). "ACL2=MOST-SPECIFIC" model: If a user belongs to multiple groups, 2). Do we need a special command for inserting <identifier, pair> at
document how rights are calculated. any position (this is meaningless for the MOST-SPECIFIC model only).
3). IANA registry for <vendorname> prefix in identifiers? 3). IANA registry for <vendorname> prefix in identifiers?
4). ACL2 interaction with QUOTA extension should be moved to "QUOTA=" 4). Do we need the following functionality: discover the set of rights
document?
5). Do we need the following functionality: 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? mailbox?
6). Cleanup appendix A before publication as RFC, as some changes don't 5). Cleanup appendix A before publication as RFC, as some changes don't
apply to RFC 2086. apply to RFC 2086.
7). Other editorial comments/questions are enclosed in << and >>. 6). Other editorial comments/questions are enclosed in << and >>.
Table of Contents Table of Contents
1 Abstract .................................................. X 1 Abstract .................................................. X
2 Conventions Used in this Document ......................... X 2 Conventions Used in this Document ......................... X
3 Introduction and Overview ................................. X 3 Introduction and Overview ................................. X
3.1 Access Control ........................................... X 3.1 Access Control ........................................... X
3.2 Access calculation model ................................. X 3.2 Access calculation model ................................. X
3.3 Rights required to perform different IMAP4rev1 commands .. X 3.3 Rights required to perform different IMAP4rev1 commands .. X
4 ACL manipulation commands ................................. X 4 ACL manipulation commands ................................. X
4.1 ACL STORE ................................................ X 4.1 ACL STORE ................................................ X
4.2 ACL DELETE ............................................... X 4.2 ACL DELETE ............................................... X
4.3 ACL SET .................................................. X 4.3 ACL SET .................................................. X
4.4 LIST with the ACL parameter .............................. X 4.4 LIST with the ACL parameter .............................. X
4.5 LIST with the MYRIGHTS parameter ......................... X 4.5 LIST with the MYRIGHTS parameter ......................... X
4.6 LIST with the POSTADDRESS parameter ...................... X
5 ACL related responses ..................................... X 5 ACL related responses ..................................... X
5.1 Extended LIST response with ACL information .............. X 5.1 Extended LIST response with ACL information .............. X
5.2 RIGHTS-INFO .............................................. X 5.2 RIGHTS-INFO .............................................. X
5.3 ACLFAILED untagged response .............................. X 5.3 ACLFAILED untagged response .............................. X
5.4 Extended LIST response with MYRIGHTS information ......... X 5.4 Extended LIST response with MYRIGHTS information ......... X
5.5 MYRIGHTS response code ................................... X 5.5 Extended LIST response with POSTADDRESS information ...... X
5.6 MYRIGHTS response code ................................... X
6 Formal Syntax ............................................. X 6 Formal Syntax ............................................. X
7 IANA considerations ....................................... X 7 IANA considerations ....................................... X
7.1 ACL access calculation rule Registration Template ........ X 7.1 ACL access calculation rule Registration Template ........ X
7.2 Initial Registrations .................................... X 7.2 Initial Registrations .................................... X
7.2.1 Registration: UNION access calculation rule ............ X 7.2.1 Registration: UNION access calculation rule ............ X
7.2.2 Registration: MOST-SPECIFIC access calculation rule .... X 7.2.2 Registration: MOST-SPECIFIC access calculation rule .... X
8 Security Considerations ................................... X 8 Security Considerations ................................... X
9 Other considerations ...................................... X 9 Other considerations ...................................... X
9.1 Compatibility with RFC 2086 .............................. X 9.1 Compatibility with RFC 2086 .............................. X
9.2 ACL2 interaction with QUOTA extension .................... X 9.2 Mapping of ACL rights to READ-WRITE and READ-ONLY
9.3 Mapping of ACL rights to READ-WRITE and READ-ONLY
response codes ........................................... X response codes ........................................... X
9.4 Additional requirements and Implementation notes ......... X 9.4 Additional requirements and Implementation notes ......... X
10 Normative References ..................................... X 10 Normative References ..................................... X
11 Informative References ................................... X 11 Informative References ................................... X
12 Aknowledgement ........................................... X 12 Aknowledgement ........................................... X
13 Editor's Address ......................................... X 13 Editor's Address ......................................... X
14 Full Copyright Statement ................................. X 14 Full Copyright Statement ................................. X
1. Abstract 1. Abstract
skipping to change at line 138 skipping to change at line 137
rights; section 3.2 introduces access calculation model, i.e. it rights; section 3.2 introduces access calculation model, i.e. it
describes how to calculate from an ACL which rigths apply to a particular describes how to calculate from an ACL which rigths apply to a particular
user; section 3.3 summarizes relationship of different access rights with user; section 3.3 summarizes relationship of different access rights with
IMAP commands; section 4 introduces new IMAP commands the client can use IMAP commands; section 4 introduces new IMAP commands the client can use
to manipulate ACLs; section 5 defines new ACL related responses; and to manipulate ACLs; section 5 defines new ACL related responses; and
section 9 lists important considerations for compatibility with [IMAP4], section 9 lists important considerations for compatibility with [IMAP4],
RFC 2086 and some IMAP extensions. RFC 2086 and some IMAP extensions.
3.1. Access Control 3.1. Access Control
An access control list is a set of <identifier,rights> pairs. An access control list is an ordered list of <identifier,rights> pairs.
An ACL applies to a mailbox. An ACL applies to a mailbox.
Identifier is a UTF-8 string. An identifier may have one of the following Identifier is a UTF-8 string. An identifier may have one of the following
forms: forms:
a). "anyone" - special identifier that refers to the universal identity a). "anonymous" - special group that refers to the universal identity
(all authentications, including anonymous). (all authentications, including anonymous). A special identifier
b). "authuser" - special identifier that refer to all authenticated users, "anyone" is a synonym for the "anonymous".
b). "authuser" - special group that refer to all authenticated users,
but not anonymous. but not anonymous.
c). "owner" - special identifier that refers to the owner of a mailbox c). "owner" - special user identifier that refers to the owner of a mailbox
(if any). (if any).
d). "administrators" - special identifier that refers to all users with d). "administrators" - special group that refers to all users with
administrative rights for the server. administrative rights for the server.
e). "user=<username>" - refers to a user. Here "<username>" is a user name e). "user=<username>" - refers to a user. Here "<username>" is a user name
string accepted by the LOGIN or AUTHENTICATE commands. string accepted by the LOGIN or AUTHENTICATE commands.
f). "group=<groupname>" - refers to a group. Here "<groupname>" is a group f). "group=<groupname>" - refers to a group. Here "<groupname>" is a group
name. name.
g). "vendor=<vendorname>.<xxx>" - refers to a vendor specific special g). "vendor=<vendorname>.<xxx>" - refers to a vendor specific special
identifier, not covered by a).-f). identifier, not covered by a).-f).
h). "-<identifier>", where <identifier> is one of a).-g). This is h). "-<identifier>", where <identifier> is one of a).-g). This is
reserved for "negative rights", described below. reserved for "negative rights", described below.
skipping to change at line 186 skipping to change at line 186
l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox) l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox)
r - read (SELECT the mailbox, perform STATUS, CHECK, FETCH, SEARCH, r - read (SELECT the mailbox, perform STATUS, CHECK, FETCH, SEARCH,
COPY from mailbox) COPY from mailbox)
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,
not enforced by IMAP4 itself. The format of the submission address not enforced by IMAP4 itself. LIST (POSTADDRESS) command can be used
is not defined by this document) to get an email address, that can be used for posting to the mailbox,
if one exist)
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 (set or clear \DELETED flag via STORE, set \DELETED flag t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag
during APPEND/COPY) during APPEND/COPY)
e - perform EXPUNGE and expunge as a part of CLOSE e - perform EXPUNGE and expunge as a part of CLOSE
d - This right is defined for backward compatibility with ACL d - This right is defined for backward compatibility with ACL
extension (RFC 2086). If a client sets "d" right, the server MUST extension (RFC 2086). If a client sets "d" right, the server MUST
set "x", "e" and "t" rights. When the client clears the "d" right, set "x", "e" and "t" rights. When the client clears the "d" right,
the server MUST clear "x", "e" and "t" rights. When all three of "x", the server MUST clear "x", "e" and "t" rights. When all three of "x",
"e" and "t" are set, the server MUST return "d" right in response to "e" and "t" are set, the server MUST return "d" right in response to
a LIST (ACL) command. If "x", "e" and "t" rights are not tied together, a LIST (ACL) command. If "x", "e" and "t" rights are not tied together,
"d" right MUST NOT be returned in a RIGHTS-INFO response. "d" right MUST NOT be returned in a RIGHTS-INFO response.
a - administer (perform ACL STORE, ACL SET and ACL DELETE) a - administer (perform ACL STORE, ACL SET and ACL DELETE)
An implementation may tie rights together or may force rights to An implementation may tie rights together or may force rights to
always or never be granted to particular identifiers. For example, always or never be granted to particular identifiers. For example,
in an implementation that uses unix mode bits, the rights "wisd" are in an implementation that uses unix mode bits, the rights "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 ACL STORE commands--unless all rights in a tied rights in response to ACL STORE commands--unless all rights in a tied
set are specified, none of that set should be included in the ACL set are specified, none of that set should be included in the ACL
entry for that identifier. If the server fails an ACL modification entry for that identifier. If the server fails an ACL modification
command (ACL STORE or ACL SET) because some rights are tied, it MUST command (ACL STORE or ACL SET) because some rights are tied, it MUST
return RIGHTS-INFO untagged response (see section 5.2). return RIGHTS-INFO untagged response (see section 5.2).
When an identifier in an ACL starts with a dash ("-"), that indicates When an identifier in an ACL starts with a dash ("-"), that indicates
skipping to change at line 496 skipping to change at line 497
specified mailbox so that the specified identifier is granted specified mailbox so that the specified identifier is granted
permissions as specified in the third argument. permissions as specified in the third argument.
The third argument is a string containing an optional plus ("+") The third argument is a string containing an optional plus ("+")
or minus ("-") prefix, followed by zero or more rights characters. or minus ("-") prefix, followed by zero or more rights characters.
If the string starts with a plus, the following rights are added If the string starts with a plus, the following rights are added
to any existing rights for the identifier. If the string starts to any existing rights for the identifier. If the string starts
with a minus, the following rights are removed from any existing with a minus, the following rights are removed from any existing
rights for the identifier. If the string does not start with a rights for the identifier. If the string does not start with a
plus or minus, the rights replace any existing rights for the plus or minus, the rights replace any existing rights for the
identifier. identifier. The combined rights will be called the "resulting" rights.
Note, that for "ACL2=UNION" access calculation rule If before execution of the command the identifier is not present
<ACL STORE mailbox identifier ""> MUST be treated as in the ACL, the <identifier, rights> pair is added to the end of
<ACL DELETE mailbox identifier>. Also note that these two commands the ACL. Otherwise it replaces the rights for the identifier,
don't have the same result for "ACL2=MOST-SPECIFIC". with the resulting rights. Note, that for the "ACL2=UNION" access
calculation model the rule <ACL STORE mailbox identifier ""> MUST
be treated as <ACL DELETE mailbox identifier>. Also note that these
two commands don't have the same result for the "ACL2=MOST-SPECIFIC"
access calculation model.
An ACL2 server MAY modify one or more ACL for one or more identifier An ACL2 server MAY modify one or more ACL for one or more identifier
as a side effect of modifying the ACL specified in ACL STORE. If the ("additional modifications") as a side effect of modifying the ACL
server does that it MUST send untagged LIST response with ACL information specified in ACL STORE. For example, in some mail stores, a mailbox can
(see section 5.1) to notify the client about the changes made. be a member of only one group. For such mailstore, doing an ACL STORE
that sets a different group from what is already in the ACL MAY have
the effect of doing an implicit ACL DELETE of the existing group's
identifier/rights pair. If the server does additional modification
it MUST send untagged LIST response with ACL information (see section 5.1)
to notify the client about the changes made.
If the server is unwilling to perform the command, because some rights If the server is unwilling to perform the command, because some rights
for the identifier are tied, it MUST return RIGHTS-INFO untagged response for the identifier are tied, it MUST return RIGHTS-INFO untagged response
(see section 5.2). (see section 5.2).
Example: C: A002 ACL STORE ~/Mail/saved user=smith cp Example: C: A002 ACL STORE ~/Mail/saved user=smith cp
S: * RIGHTS-INFO ~/Mail/saved user=smith la r swi cdext p S: * RIGHTS-INFO ~/Mail/saved user=smith la r swi cdext p
S: A002 NO Acl store failed, some rights are tied S: A002 NO Acl store failed, some rights are tied
Client decides to grant both rights to the identifier: Client decides to grant both rights to the identifier:
C: A003 ACL STORE ~/Mail/saved smith cdextp C: A003 ACL STORE ~/Mail/saved user=smith cdextp
S: A003 OK Setacl complete S: A003 OK Setacl complete
The following example demonstrates behaviour of a mail store that allows
a mailbox to be a member of only one group:
C: B001 LIST (ACL) "" INBOX
S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") (
"group=Devel" "rwipslt"))))
S: B001 OK List with acl info completed
C: B002 ACL STORE Inbox group=PSO rwipslte
S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") (
"group=PSO" "rwipslte"))))
S: B002 OK Setacl complete
4.2. ACL DELETE 4.2. ACL DELETE
Arguments: mailbox name or one or more mailbox masks Arguments: mailbox name or one or more mailbox masks
authentication identifier authentication identifier
Data: OPTIONAL untagged responses: LIST with ACL information (see 5.1) Data: OPTIONAL untagged responses: LIST with ACL information (see 5.1)
Result: OK - ACL DELETE completed Result: OK - ACL DELETE completed
NO - ACL DELETE failure: can't delete acl NO - ACL DELETE failure: can't delete acl
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
skipping to change at line 603 skipping to change at line 625
The user must have any of the following rights to perform this operation: The user must have any of the following rights to perform this operation:
"l", "r", "i", "c", "x", "e", "a". "l", "r", "i", "c", "x", "e", "a".
If the user doesn't have any right from the above list, the server If the user doesn't have any right from the above list, the server
MUST behave as if the mailbox doesn't exist. MUST behave as if the mailbox doesn't exist.
Example: C: A002 LIST (MYRIGHTS) "" INBOX Example: C: A002 LIST (MYRIGHTS) "" INBOX
S: * LIST () "/" INBOX (("MYRIGHTS" "rwipsldexta")) S: * LIST () "/" INBOX (("MYRIGHTS" "rwipsldexta"))
S: A002 OK List with acl info completed S: A002 OK List with acl info completed
4.6. LIST with the POSTADDRESS parameter
This document defines a new option POSTADDRESS to the LIST command that requests
the server to return an email address that can be used to post email to a mailbox,
that matches the LIST mailbox name. The POSTADDRESS option causes the server
to return LIST with POSTADDRESS information (see 5.5).
Example: C: A002 LIST (POSTADDRESS) "" INBOX
S: * LIST () "/" INBOX (("POSTADDRESS" "user1@example.com"))
S: A002 OK List with postaddress info completed
5. ACL related responses 5. ACL related responses
5.1. Extended LIST response with ACL information 5.1. Extended LIST response with ACL information
Contents: name attributes Contents: name attributes
hierarchy delimiter hierarchy delimiter
mailbox name mailbox name
ACL information (zero or more identifier rights pairs) ACL information (zero or more identifier rights pairs)
This version of LIST response occurs as a result of an LIST (ACL) command. This version of LIST response occurs as a result of an LIST (ACL) command.
skipping to change at line 637 skipping to change at line 670
The example above shows that a user Fred is granted "rwipslextda" The example above shows that a user Fred is granted "rwipslextda"
rights to the mailbox "INBOX". rights to the mailbox "INBOX".
S: * LIST () ":" Drafts (("ACL" S: * LIST () ":" Drafts (("ACL"
(("user=Fred" "rwipslextda") ("group=Devel" "r")))) (("user=Fred" "rwipslextda") ("group=Devel" "r"))))
The example above shows that a user Fred is granted "rwipslextda" The example above shows that a user Fred is granted "rwipslextda"
rights and a member of a group "Devel" is granted "r" right to rights and a member of a group "Devel" is granted "r" right to
the mailbox "Drafts". the mailbox "Drafts".
S: * LIST () NIL Manson (("ACL" ())) S: * LIST () NIL Manson (("ACL" NIL))
The example above shows the mailbox "Manson" has an empty ACL. The example above shows the mailbox "Manson" has an empty ACL.
5.2. RIGHTS-INFO 5.2. RIGHTS-INFO
Data: mailbox name Data: mailbox name
identifier identifier
required rights required rights
list of optional rights list of optional rights
skipping to change at line 698 skipping to change at line 731
LIST response as defined by mbox-list-extended ABNF element of [LISTEXT]. LIST response as defined by mbox-list-extended ABNF element of [LISTEXT].
The meaning of "name attributes" and "hierarchy delimiter" is described in The meaning of "name attributes" and "hierarchy delimiter" is described in
section 7.2.2 of [IMAP4]. This is followed by the extension part that section 7.2.2 of [IMAP4]. This is followed by the extension part that
includes "MYRIGHTS" tag followed by the set of rights that the user has. includes "MYRIGHTS" tag followed by the set of rights that the user has.
<<Should this be simplified so that we don't repeat general LIST[EXT] stuff?>> <<Should this be simplified so that we don't repeat general LIST[EXT] stuff?>>
Example: S: * LIST () "/" Sent (("MYRIGHTS" "lrwiste")) Example: S: * LIST () "/" Sent (("MYRIGHTS" "lrwiste"))
5.5. MYRIGHTS response code 5.5. Extended LIST response with POSTADDRESS information
Contents: name attributes
hierarchy delimiter
mailbox name
email address for posting to the mailbox
This version of LIST response occurs as a result of a LIST (POSTADDRESS)
command. The proposed syntax conforms to the syntax of an extended
LIST response as defined by mbox-list-extended ABNF element of [LISTEXT].
The meaning of "name attributes" and "hierarchy delimiter" is described in
section 7.2.2 of [IMAP4]. This is followed by the extension part that
includes "POSTADDRESS" tag followed by an email address that can be used
to post email to the mailbox.
Example: S: * LIST () "/" Sent (("POSTADDRESS" "user+Sent@imap.example.com"))
5.6. MYRIGHTS response code
Data: rights Data: rights
The MYRIGHTS response code is sent in an untagged OK response The MYRIGHTS response code is sent in an untagged OK response
that results from SELECT/EXAMINE. Also this response code can be that results from SELECT/EXAMINE. Also this response code can be
sent at any time after opening a mailbox when the server detects sent at any time after opening a mailbox when the server detects
that the set of rights allowed for the logged in user has changed. that the set of rights allowed for the logged in user has changed.
The MYRIGHTS response code is equivalent to the MYRIGHTS data returned The MYRIGHTS response code is equivalent to the MYRIGHTS data returned
in an untagged LIST response for the selected mailbox. in an untagged LIST response for the selected mailbox.
skipping to change at line 733 skipping to change at line 784
acl2_subcommand = replaceacl | deleteacl | updateacl acl2_subcommand = replaceacl | deleteacl | updateacl
acl_list_data = "(" acl_list_tag SP acl_data ")" acl_list_data = "(" acl_list_tag SP acl_data ")"
;; acl_list_data conforms to the syntax of ;; acl_list_data conforms to the syntax of
;; mbox-list-extended-item from [LISTEXT] ;; mbox-list-extended-item from [LISTEXT]
acl_list_tag = <"> "ACL" <"> acl_list_tag = <"> "ACL" <">
ace = "(" identifier SP rights ")" ace = "(" identifier SP rights ")"
acl_data = "(" [ace *( SP ace )] ")" acl_data = "NIL" | acl_data_nonemp
;; zero or more parenthesized identifier/rights pairs ;; NIL, or one or more parenthesized identifier/rights pairs
<<Currently the empty list doesn't conform to mbox-list-extended-item syntax!>> acl_data_nonemp = "(" ace *( SP ace ) ")"
always_granted = rights always_granted = rights
deleteacl = "DELETE" SP mbox_or_pat SP identifier deleteacl = "DELETE" SP mbox_or_pat SP identifier
option =/ "ACL" | "MYRIGHTS" option =/ "ACL" | "MYRIGHTS" | "POSTADDRESS"
;; <option> is defined in [LISTEXT] ;; <option> is defined in [LISTEXT]
identifier = astring identifier = astring
;; UTF-8 string with syntax of ident_syntax ;; UTF-8 string with syntax of ident_syntax
ident_syntax = ident | "-" ident ident_syntax = ident | "-" ident
ident = ident_special | ident_user | ident_group | ident = ident_special | ident_user | ident_group |
ident_vendor ident_vendor
ident_special = "anyone" | "authuser" | "owner" | "administrators" ident_special = "anyone" | "anonymous" | "authuser" | "owner" | "administrators"
ident_user = "user=" ident_detail ident_user = "user=" ident_detail
ident_group = "group=" ident_detail ident_group = "group=" ident_detail
ident_vendor = "vendor=" ident_vname "." ident_detail ident_vendor = "vendor=" ident_vname "." ident_detail
ident_detail = 1*UTF8-CHAR ident_detail = 1*UTF8-CHAR
ident_vname = 1*UTF8-CHAR ident_vname = 1*UTF8-CHAR
;; MUST NOT contain "." ;; MUST NOT contain "."
listrights_data = "RIGHTS-INFO" SP mailbox SP identifier listrights_data = "RIGHTS-INFO" SP mailbox SP identifier
SP always_granted *(SP rights) SP always_granted *(SP rights)
mod_rights = quoted mod_rights = quoted
;; +rights to add, -rights to remove ;; +rights to add, -rights to remove
myrights_list_data myrights_list_data
= "(" "MYRIGHTS" SP rights ")" = "(" <"> "MYRIGHTS" <"> SP rights ")"
;; myrights_list_data conforms to the syntax of ;; myrights_list_data conforms to the syntax of
;; mbox-list-extended-item from [LISTEXT] ;; mbox-list-extended-item from [LISTEXT]
myrights_rspcod = "MYRIGHTS" SP rights myrights_rspcod = "MYRIGHTS" SP rights
replaceacl = "SET" SP mbox_or_pat *(SP identifier SP rights) replaceacl = "SET" SP mbox_or_pat *(SP identifier SP rights)
resp-text-code =/ myrights_rspcod resp-text-code =/ myrights_rspcod
rights = quoted rights = quoted
skipping to change at line 797 skipping to change at line 848
mbox_or_pat = mailbox / patterns mbox_or_pat = mailbox / patterns
patterns = "(" list-mailbox *(list-mailbox) ")" patterns = "(" list-mailbox *(list-mailbox) ")"
partialfail_rsp = "ACLFAILED" SP mailbox partialfail_rsp = "ACLFAILED" SP mailbox
[SP ["[" resp-text-code "]" SP] text] [SP ["[" resp-text-code "]" SP] text]
;; May contain optional failure reason followed by a ;; May contain optional failure reason followed by a
;; human readable text ;; human readable text
postaddress_data
= "(" <"> "POSTADDRESS" <"> SP email_address ")"
;; postaddress_data conforms to the syntax of
;; mbox-list-extended-item from [LISTEXT]
email_address = nstring
;; NIL if email address is not known
UTF8-CHAR = CHAR | UTF8-2 | UTF8-3 | UTF8-4 | UTF8-5 | UTF8-6 UTF8-CHAR = CHAR | UTF8-2 | UTF8-3 | UTF8-4 | UTF8-5 | UTF8-6
CHAR = %x01-7F CHAR = %x01-7F
UTF8-loworder = %x80-BF UTF8-loworder = %x80-BF
UTF8-2 = %xC1-DF UTF8-loworder UTF8-2 = %xC1-DF UTF8-loworder
;; Disallow overlong sequences beginning with 0xC0. ;; Disallow overlong sequences beginning with 0xC0.
UTF8-3 = (%xE0 %xA0-BF UTF8-loworder) | UTF8-3 = (%xE0 %xA0-BF UTF8-loworder) |
skipping to change at line 863 skipping to change at line 922
Rule Identification: UNION Rule Identification: UNION
Rule Semantics: the union of the rights granted to Rule Semantics: the union of the rights granted to
the applicable identifiers minus the union of the negative rights. the applicable identifiers minus the union of the negative rights.
Negative rights allowed: Yes. Negative rights allowed: Yes.
Groups allowed: Yes, but not required. Groups allowed: Yes, but not required.
Special Identifiers: No. Special Identifiers: Any of "anonymous"/"anyone", "authuser", "owner",
"administrators" MAY be supported.
Contact Information: c.f., the "Editor's Address" section of this Contact Information: c.f., the "Editor's Address" section of this
memo memo
7.2.2. Registration: MOST-SPECIFIC access calculation rule 7.2.2. Registration: MOST-SPECIFIC access calculation rule
Rule Identification: MOST-SPECIFIC Rule Identification: MOST-SPECIFIC
Rule Semantics: the rights granted to the most specific identifier Rule Semantics: the rights granted to the most specific identifier
present in the ACL are used, i.e. if the user identifier is present, 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 (or a special identifier that references the user), its ACL is used.
includes this user as a member is present, the group ACL is used. If no user identifier is present, but a group (or a special group)
If neither user, nor group identifier is present, but an ACL for that includes this user as a direct or indirect member (as a member
a special group "anyone" is present, the ACL for "anyone" is used. of a subgroup) is present, the group ACL is used. If neither user,
nor group identifier is present, the user has no rights. If multiple
groups apply to the user, rights of the first one in the ACL are used.
Note, that as the identifiers "anonymous", "anyone", "authuser",
"administrators" are just special groups, the same rule apply to them.
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: Any of "anonymous"/"anyone", "authuser", "owner",
"administrators" MAY be supported.
Contact Information: c.f., the "Editor's Address" section of this Contact Information: c.f., the "Editor's Address" section of this
memo memo
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 LIST (ACL) command on a mailbox for which the user has For example, a LIST (ACL) 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.
<<Add security considerations for POSTADDRESS option: address harvesting
for spam, rights required>>
IMAP clients implementing ACL2 that are able to modify ACLs SHOULD IMAP clients implementing ACL2 that are able to modify ACLs SHOULD
warn a user that wants to give full access (or even just "a" right) warn a user that wants to give full access (or even just "a" right)
to the special identifier "anyone". to the special identifier "anyone".
9. Other considerations 9. Other considerations
9.1. Compatibility with RFC 2086 9.1. Compatibility with RFC 2086
This section gives guidelines how an existing RFC 2086 implementation This section gives guidelines how an existing RFC 2086 implementation
may be modified to support ACL2. may be modified to support ACL2.
skipping to change at line 945 skipping to change at line 1013
4). Optional: send MYRIGHTS untagged response on SELECT/EXAMINE 4). Optional: send MYRIGHTS untagged response on SELECT/EXAMINE
5). LISTRIGHTS command is deprecated. LISTRIGHTS response is replaced 5). LISTRIGHTS command is deprecated. LISTRIGHTS response is replaced
with RIGHTS-INFO response code. with RIGHTS-INFO response code.
6). Report "ACL2=UNION" capability. 6). Report "ACL2=UNION" capability.
7). Implement new special identifiers or groups if desired. 7). Implement new special identifiers or groups if desired.
9.2. ACL2 interaction with QUOTA extension 9.2. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes
Server that implement both ACL2 and QUOTA extensions MUST use the following
table to determine if a quota operation should be allowed for the user:
GETQUOTAROOT - any of the following rights is required to perform the
operation: "r", "i", "a".
<<"r" allows to calculate usage, "i" allows to put a mailbox overquota and get
mailbox usage with certain implementations, that check message size
before receiving the message in APPEND>>
GETQUOTA - no rights required
SETQUOTA - implementation defined, as SETQUOTA operates on a quotaroot,
not on a mailbox.
9.3. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes
A particular ACL2 server implementation may allow "shared multiuser A particular ACL2 server implementation may allow "shared multiuser
access" to some mailboxes. "Shared multiuser access" to a mailbox means access" to some mailboxes. "Shared multiuser access" to a mailbox means
that multiple different users are able to access the same mailbox, that multiple different users are able to access the same mailbox,
if they have proper access rights. "Shared multiuser access" to the if they have proper access rights. "Shared multiuser access" to the
mailbox doesn't mean that the ACL for the mailbox is currently set mailbox doesn't mean that the ACL for the mailbox is currently set
to allow access by multiple users. Let's denote a "shared multiuser 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").
skipping to change at line 1064 skipping to change at line 1115
[ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
November 1997. November 1997.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, University of Washington, March 2003. 4rev1", RFC 3501, University of Washington, March 2003.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646",
RFC 2279, Alis Technologies, January 1998. RFC 2279, Alis Technologies, January 1998.
[QUOTA] Myers, J., "IMAP4 QUOTA extension", RFC 2087, Carnegie Mellon
University, January 1997.
11. Informative References 11. Informative References
[LISTEXT] Leiba, B., "IMAP4 LIST Command Extensions", work in progress, [LISTEXT] Leiba, B., "IMAP4 LIST Command Extensions", work in progress,
draft-ietf-imapext-list-extensions-02.txt, IBM T.J. Watson Research draft-ietf-imapext-list-extensions-02.txt, IBM T.J. Watson Research
Center. Center.
12. Aknowledgement 12. Aknowledgement
This document is a revision of the RFC 2086 written by John G. Myers. This document is a revision of the RFC 2086 written by John G. Myers.
Editor appreciates comments received from Mark Crispin, Chris Newman, Editor appreciates comments received from Mark Crispin, Chris Newman,
Cyrus Daboo, John G. Myers, Steve Hole, Curtis King, Lyndon Nerenberg, Cyrus Daboo, John G. Myers, Steve Hole, Curtis King, Lyndon Nerenberg,
Larry Greenfield, Vladimir Butenko, Dave Cridland, Harrie Hazewinkel Larry Greenfield, Vladimir Butenko, Dave Cridland, Harrie Hazewinkel
and other participants of IMAPEXT working group. and other participants of the IMAPEXT working group.
13. Editor's Address 13. Editor's Address
Alexey Melnikov Alexey Melnikov
mailto: mel@isode.com mailto: mel@isode.com
Isode Limited Isode Limited
14. Full Copyright Statement 14. Full Copyright Statement
skipping to change at line 1242 skipping to change at line 1290
42. Added notes that group and administrators management, as well as 42. Added notes that group and administrators management, as well as
the format of an email for posting to a mailbox is out of scope. the format of an email for posting to a mailbox is out of scope.
43. Added a table that describes all operations and right required to 43. Added a table that describes all operations and right required to
perform them. perform them.
44. Fixed several MYRIGHTS examples. 44. Fixed several MYRIGHTS examples.
45. Updated ABNF to reflect recent changes ("MYRIGHTS" to "LIST (MYRIGHTS)" 45. Updated ABNF to reflect recent changes ("MYRIGHTS" to "LIST (MYRIGHTS)"
and "ACL GET" to "LIST (ACL)") and "ACL GET" to "LIST (ACL)")
46. Added LIST (POSTADDRESS).
47. Updated ACL ABNF to represent an empty ACL with NIL, instead of "()".
48. Added "anonymous" as a synonym for the "anyone".
49. Moved section about interaction of ACL2 with the QUOTA extension to
the QUOTA+ document.
50. Clarified that "anonymous", "anyone", "authuser", "administrators"
should be treated as groups.
51. Changed ACL definition to be an "ordered list", instead of a "set".
This has no effect on UNION model, but changes MOST-SPECIFIC.
52. Clarified that for the MOST-SPECIFIC model the first group in an ACL
that contains the user wins.
 End of changes. 

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