imapext-2007
diff docs/rfc/rfc4314.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/docs/rfc/rfc4314.txt Mon Sep 14 15:17:45 2009 +0900 1.3 @@ -0,0 +1,1515 @@ 1.4 + 1.5 + 1.6 + 1.7 + 1.8 + 1.9 + 1.10 +Network Working Group A. Melnikov 1.11 +Request for Comments: 4314 Isode Ltd. 1.12 +Obsoletes: 2086 December 2005 1.13 +Category: Standards Track 1.14 + 1.15 + 1.16 + IMAP4 Access Control List (ACL) Extension 1.17 + 1.18 +Status of this Memo 1.19 + 1.20 + This document specifies an Internet standards track protocol for the 1.21 + Internet community, and requests discussion and suggestions for 1.22 + improvements. Please refer to the current edition of the "Internet 1.23 + Official Protocol Standards" (STD 1) for the standardization state 1.24 + and status of this protocol. Distribution of this memo is unlimited. 1.25 + 1.26 +Copyright Notice 1.27 + 1.28 + Copyright (C) The Internet Society (2005). 1.29 + 1.30 +Abstract 1.31 + 1.32 + The Access Control List (ACL) extension (RFC 2086) of the Internet 1.33 + Message Access Protocol (IMAP) permits mailbox access control lists 1.34 + to be retrieved and manipulated through the IMAP protocol. 1.35 + 1.36 + This document is a revision of RFC 2086. It defines several new 1.37 + access control rights and clarifies which rights are required for 1.38 + different IMAP commands. 1.39 + 1.40 + 1.41 + 1.42 + 1.43 + 1.44 + 1.45 + 1.46 + 1.47 + 1.48 + 1.49 + 1.50 + 1.51 + 1.52 + 1.53 + 1.54 + 1.55 + 1.56 + 1.57 + 1.58 + 1.59 + 1.60 + 1.61 +Melnikov Standards Track [Page 1] 1.62 + 1.63 +RFC 4314 IMAP ACL December 2005 1.64 + 1.65 + 1.66 +Table of Contents 1.67 + 1.68 + 1. Introduction and Overview .......................................3 1.69 + 1.1. Conventions Used in This Document ..........................3 1.70 + 2. Access Control ..................................................3 1.71 + 2.1. Standard Rights ............................................5 1.72 + 2.1.1. Obsolete Rights .....................................5 1.73 + 2.2. Rights Defined in RFC 2086 .................................8 1.74 + 3. Access control management commands and responses ................8 1.75 + 3.1. SETACL Command .............................................8 1.76 + 3.2. DELETEACL Command ..........................................9 1.77 + 3.3. GETACL Command ............................................10 1.78 + 3.4. LISTRIGHTS Command ........................................10 1.79 + 3.5. MYRIGHTS Command ..........................................11 1.80 + 3.6. ACL Response ..............................................11 1.81 + 3.7. LISTRIGHTS Response .......................................12 1.82 + 3.8. MYRIGHTS Response .........................................12 1.83 + 4. Rights Required to Perform Different IMAP4rev1 Commands ........12 1.84 + 5. Other Considerations ...........................................17 1.85 + 5.1. Additional Requirements and Implementation Notes ..........17 1.86 + 5.1.1. Servers ............................................17 1.87 + 5.1.2. Clients ............................................18 1.88 + 5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY 1.89 + Response Codes ............................................19 1.90 + 6. Security Considerations ........................................20 1.91 + 7. Formal Syntax ..................................................21 1.92 + 8. IANA Considerations ............................................22 1.93 + 9. Internationalization Considerations ............................22 1.94 + Appendix A. Changes since RFC 2086 ................................23 1.95 + Appendix B. Compatibility with RFC 2086 ...........................24 1.96 + Appendix C. Known Deficiencies ....................................24 1.97 + Appendix D. Acknowledgements ......................................25 1.98 + Normative References ..............................................25 1.99 + Informative References ............................................25 1.100 + 1.101 + 1.102 + 1.103 + 1.104 + 1.105 + 1.106 + 1.107 + 1.108 + 1.109 + 1.110 + 1.111 + 1.112 + 1.113 + 1.114 + 1.115 + 1.116 + 1.117 +Melnikov Standards Track [Page 2] 1.118 + 1.119 +RFC 4314 IMAP ACL December 2005 1.120 + 1.121 + 1.122 +1. Introduction and Overview 1.123 + 1.124 + The ACL (Access Control List) extension of the Internet Message 1.125 + Access Protocol [IMAP4] permits mailbox access control lists to be 1.126 + retrieved and manipulated through the IMAP protocol. 1.127 + 1.128 + This document is a revision of RFC 2086 [RFC2086]. It tries to 1.129 + clarify different ambiguities in RFC 2086, in particular, the use of 1.130 + UTF-8 [UTF-8] in access identifiers, which rights are required for 1.131 + different IMAP4 commands, and how READ-WRITE/READ-ONLY response codes 1.132 + are related to ACL. 1.133 + 1.134 +1.1. Conventions Used in This Document 1.135 + 1.136 + In examples, "C:" and "S:" indicate lines sent by the client and 1.137 + server respectively. 1.138 + 1.139 + In all examples "/" character is used as hierarchy separator. 1.140 + 1.141 + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1.142 + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1.143 + document are to be interpreted as described in RFC 2119 [KEYWORDS]. 1.144 + 1.145 + The phrase "ACL server" is just a shortcut for saying "IMAP server 1.146 + that supports ACL extension as defined in this document". 1.147 + 1.148 +2. Access Control 1.149 + 1.150 + The ACL extension is present in any IMAP4 implementation that returns 1.151 + "ACL" as one of the supported capabilities to the CAPABILITY command. 1.152 + 1.153 + A server implementation conformant to this document MUST also return 1.154 + rights (see below) not defined in Section 2.2 in the "RIGHTS=" 1.155 + capability. 1.156 + 1.157 + An access control list is a set of <access identifier,rights> pairs. 1.158 + An ACL applies to a mailbox name. 1.159 + 1.160 + Access identifier (or just "identifier") is a UTF-8 [UTF-8] string. 1.161 + The identifier "anyone" is reserved to refer to the universal 1.162 + identity (all authentications, including anonymous). All user name 1.163 + strings accepted by the LOGIN or AUTHENTICATE commands to 1.164 + authenticate to the IMAP server are reserved as identifiers for the 1.165 + corresponding users. Identifiers starting with a dash ("-") are 1.166 + reserved for "negative rights", described below. All other 1.167 + identifier strings are interpreted in an implementation-defined 1.168 + manner. 1.169 + 1.170 + 1.171 + 1.172 + 1.173 +Melnikov Standards Track [Page 3] 1.174 + 1.175 +RFC 4314 IMAP ACL December 2005 1.176 + 1.177 + 1.178 + Rights is a string listing a (possibly empty) set of alphanumeric 1.179 + characters, each character listing a set of operations that is being 1.180 + controlled. Lowercase letters are reserved for "standard" rights, 1.181 + listed in Section 2.1. (Note that for compatibility with deployed 1.182 + clients and servers uppercase rights are not allowed.) The set of 1.183 + standard rights can only be extended by a standards-track document. 1.184 + Digits are reserved for implementation- or site-defined rights. 1.185 + 1.186 + An implementation MAY tie rights together or MAY force rights to 1.187 + always or never be granted to particular identifiers. For example, 1.188 + in an implementation that uses UNIX mode bits, the rights "swite" are 1.189 + tied, the "a" right is always granted to the owner of a mailbox and 1.190 + is never granted to another user. If rights are tied in an 1.191 + implementation, the implementation must be conservative in granting 1.192 + rights in response to SETACL commands--unless all rights in a tied 1.193 + set are specified, none of that set should be included in the ACL 1.194 + entry for that identifier. A client can discover the set of rights 1.195 + that may be granted to a given identifier in the ACL for a given 1.196 + mailbox name by using the LISTRIGHTS command. 1.197 + 1.198 + It is possible for multiple identifiers in an access control list to 1.199 + apply to a given user. For example, an ACL may include rights to be 1.200 + granted to the identifier matching the user, one or more 1.201 + implementation-defined identifiers matching groups that include the 1.202 + user, and/or the identifier "anyone". How these rights are combined 1.203 + to determine the user's access is implementation defined. An 1.204 + implementation may choose, for example, to use the union of the 1.205 + rights granted to the applicable identifiers. An implementation may 1.206 + instead choose, for example, to use only those rights granted to the 1.207 + most specific identifier present in the ACL. A client can determine 1.208 + the set of rights granted to the logged-in user for a given mailbox 1.209 + name by using the MYRIGHTS command. 1.210 + 1.211 + When an identifier in an ACL starts with a dash ("-"), that indicates 1.212 + that associated rights are to be removed from the identifier prefixed 1.213 + by the dash. This is referred to as a "negative right". This 1.214 + differs from DELETEACL in that a negative right is added to the ACL 1.215 + and is a part of the calculation of the rights. 1.216 + 1.217 + Let's assume that an identifier "fred" refers to a user with login 1.218 + "fred". If the identifier "-fred" is granted the "w" right, that 1.219 + indicates that the "w" right is to be removed from users matching the 1.220 + identifier "fred", even though the user "fred" might have the "w" 1.221 + right as a consequence of some other identifier in the ACL. A 1.222 + DELETEACL of "fred" simply deletes the identifier "fred" from the 1.223 + ACL; it does not affect any rights that the user "fred" may get from 1.224 + another entry in the ACL, in particular it doesn't affect rights 1.225 + granted to the identifier "-fred". 1.226 + 1.227 + 1.228 + 1.229 +Melnikov Standards Track [Page 4] 1.230 + 1.231 +RFC 4314 IMAP ACL December 2005 1.232 + 1.233 + 1.234 + Server implementations are not required to support "negative right" 1.235 + identifiers. 1.236 + 1.237 +2.1. Standard Rights 1.238 + 1.239 + The currently defined standard rights are (note that the list below 1.240 + doesn't list all commands that use a particular right): 1.241 + 1.242 + l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE 1.243 + mailbox) 1.244 + r - read (SELECT the mailbox, perform STATUS) 1.245 + s - keep seen/unseen information across sessions (set or clear 1.246 + \SEEN flag via STORE, also set \SEEN during APPEND/COPY/ 1.247 + FETCH BODY[...]) 1.248 + w - write (set or clear flags other than \SEEN and \DELETED via 1.249 + STORE, also set them during APPEND/COPY) 1.250 + i - insert (perform APPEND, COPY into mailbox) 1.251 + p - post (send mail to submission address for mailbox, 1.252 + not enforced by IMAP4 itself) 1.253 + k - create mailboxes (CREATE new sub-mailboxes in any 1.254 + implementation-defined hierarchy, parent mailbox for the new 1.255 + mailbox name in RENAME) 1.256 + x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) 1.257 + t - delete messages (set or clear \DELETED flag via STORE, set 1.258 + \DELETED flag during APPEND/COPY) 1.259 + e - perform EXPUNGE and expunge as a part of CLOSE 1.260 + a - administer (perform SETACL/DELETEACL/GETACL/LISTRIGHTS) 1.261 + 1.262 +2.1.1. Obsolete Rights 1.263 + 1.264 + Due to ambiguity in RFC 2086, some existing RFC 2086 server 1.265 + implementations use the "c" right to control the DELETE command. 1.266 + Others chose to use the "d" right to control the DELETE command. For 1.267 + the former group, let's define the "create" right as union of the "k" 1.268 + and "x" rights, and the "delete" right as union of the "e" and "t" 1.269 + rights. For the latter group, let's define the "create" rights as a 1.270 + synonym to the "k" right, and the "delete" right as union of the "e", 1.271 + "t", and "x" rights. 1.272 + 1.273 + For compatibility with RFC 2086, this section defines two virtual 1.274 + rights "d" and "c". 1.275 + 1.276 + If a client includes the "d" right in a rights list, then it MUST be 1.277 + treated as if the client had included every member of the "delete" 1.278 + right. (It is not an error for a client to specify both the "d" 1.279 + right and one or more members of the "delete" right, but the effect 1.280 + is no different than if just the "d" right or all members of the 1.281 + "delete" right had been specified.) 1.282 + 1.283 + 1.284 + 1.285 +Melnikov Standards Track [Page 5] 1.286 + 1.287 +RFC 4314 IMAP ACL December 2005 1.288 + 1.289 + 1.290 + When any of the "delete" member rights is set in a list of rights, 1.291 + the server MUST also include the "d" right when returning the list in 1.292 + a MYRIGHTS or ACL response. This is to enable older clients 1.293 + conforming to RFC 2086 to work with newer servers. (*) 1.294 + 1.295 + Example: C: A001 SeTacl INBOX/Drafts David lrswida 1.296 + S: A001 OK Setacl complete 1.297 + 1.298 + The client has specified the "d" right in the SETACL command above 1.299 + and it expands to "et" on the server: 1.300 + 1.301 + C: A002 getacl INBOX/Drafts 1.302 + S: * ACL INBOX Fred rwipslxcetda David lrswideta 1.303 + S: A002 OK Getacl complete 1.304 + 1.305 + If the identifier specified in the LISTRIGHTS command can be granted 1.306 + any of the "delete" member rights on a mailbox, then the server MUST 1.307 + include the "d" right in the corresponding LISTRIGHTS response. (*) 1.308 + If the member rights aren't tied to non-member rights, then the "d" 1.309 + right is returned by itself in the LISTRIGHTS response. If any of 1.310 + the member rights needs to be tied to one (or more) non-member right, 1.311 + then the "d" right and all of the member rights need to be tied to 1.312 + the same non-member right(s) (**). 1.313 + 1.314 + If a client includes the "c" right in a rights list, then it MUST be 1.315 + treated as if the client had included every member of the "create" 1.316 + right. (It is not an error for a client to specify both the "c" 1.317 + right and one or more members of the "create" right, but the effect 1.318 + is no different than if just the "c" right or all members of the 1.319 + "create" right had been specified.) 1.320 + 1.321 + When any of the "create" member rights is set in a list of rights, 1.322 + the server MUST also include the "c" right when returning the list in 1.323 + a MYRIGHTS or ACL response. This is to enable older clients 1.324 + conforming to RFC 2086 to work with newer servers. (*) 1.325 + 1.326 + Example: C: A003 Setacl INBOX/Drafts Byron lrswikda 1.327 + S: A001 OK Setacl complete 1.328 + C: A002 getAcl INBOX/Drafts 1.329 + S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta 1.330 + S: A002 OK Getacl complete 1.331 + 1.332 + The client has specified the "d" right in the SETACL command above 1.333 + and it expands to "et" on the server: As the client has specified the 1.334 + "k" right (which is a member of the "c" right), the server also 1.335 + returns the "c" right. 1.336 + 1.337 + 1.338 + 1.339 + 1.340 + 1.341 +Melnikov Standards Track [Page 6] 1.342 + 1.343 +RFC 4314 IMAP ACL December 2005 1.344 + 1.345 + 1.346 + If the identifier specified in the LISTRIGHTS command can be granted 1.347 + any of the "create" member rights on a mailbox, then the server MUST 1.348 + include the "c" right in the corresponding LISTRIGHTS response. (*) 1.349 + If the member rights aren't tied to non-member rights, then the "c" 1.350 + right is returned by itself in the LISTRIGHTS response. If any of 1.351 + the member rights needs to be tied to one (or more) non-member right, 1.352 + then the "c" right and all of the member rights need to be tied to 1.353 + the same non-member right(s) (**). 1.354 + 1.355 + Example: The server that ties the rights as follows: 1.356 + 1.357 + lr s w i p k x t 1.358 + 1.359 + and c=k 1.360 + 1.361 + will return: 1.362 + 1.363 + S: * LISTRIGHTS archive/imap anyone "" 1.364 + lr s w i p k x t c d 1.365 + 1.366 + Example: The server that ties the rights as follows: 1.367 + 1.368 + lr s w i p k xte 1.369 + 1.370 + and c=k 1.371 + 1.372 + will return: 1.373 + 1.374 + S: * LISTRIGHTS archive/imap anyone "" 1.375 + lr s w i p k xte c d 1.376 + 1.377 + Example: The server that ties the rights as follows: 1.378 + 1.379 + lr s w i p k x te 1.380 + 1.381 + and c=k 1.382 + 1.383 + will return: 1.384 + 1.385 + S: * LISTRIGHTS archive/imap anyone "" 1.386 + lr s w i p k c x te d 1.387 + 1.388 + Example: The server that ties the rights as follows: 1.389 + 1.390 + lr swte i p k x 1.391 + 1.392 + and c=kx 1.393 + 1.394 + 1.395 + 1.396 + 1.397 +Melnikov Standards Track [Page 7] 1.398 + 1.399 +RFC 4314 IMAP ACL December 2005 1.400 + 1.401 + 1.402 + will return: 1.403 + 1.404 + S: * LISTRIGHTS archive/imap anyone "" 1.405 + lr swted i p k x c 1.406 + 1.407 + (*) Clients conforming to this document MUST ignore the virtual "d" 1.408 + and "c" rights in MYRIGHTS, ACL, and LISTRIGHTS responses. 1.409 + 1.410 + (**) The IMAPEXT Working Group has debated this issue in great length 1.411 + and after reviewing existing ACL implementations concluded that 1.412 + this is a reasonable restriction. 1.413 + 1.414 +2.2. Rights Defined in RFC 2086 1.415 + 1.416 + The "RIGHTS=" capability MUST NOT include any of the rights defined 1.417 + in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the 1.418 + digits ("0" .. "9"). 1.419 + 1.420 +3. Access control management commands and responses 1.421 + 1.422 + Servers, when processing a command that has an identifier as a 1.423 + parameter (i.e., any of SETACL, DELETEACL, and LISTRIGHTS commands), 1.424 + SHOULD first prepare the received identifier using "SASLprep" profile 1.425 + [SASLprep] of the "stringprep" algorithm [Stringprep]. If the 1.426 + preparation of the identifier fails or results in an empty string, 1.427 + the server MUST refuse to perform the command with a BAD response. 1.428 + Note that Section 6 recommends additional identifier's verification 1.429 + steps. 1.430 + 1.431 +3.1. SETACL Command 1.432 + 1.433 + Arguments: mailbox name 1.434 + identifier 1.435 + access right modification 1.436 + 1.437 + Data: no specific data for this command 1.438 + 1.439 + Result: OK - setacl completed 1.440 + NO - setacl failure: can't set acl 1.441 + BAD - arguments invalid 1.442 + 1.443 + The SETACL command changes the access control list on the specified 1.444 + mailbox so that the specified identifier is granted permissions as 1.445 + specified in the third argument. 1.446 + 1.447 + The third argument is a string containing an optional plus ("+") or 1.448 + minus ("-") prefix, followed by zero or more rights characters. If 1.449 + the string starts with a plus, the following rights are added to any 1.450 + 1.451 + 1.452 + 1.453 +Melnikov Standards Track [Page 8] 1.454 + 1.455 +RFC 4314 IMAP ACL December 2005 1.456 + 1.457 + 1.458 + existing rights for the identifier. If the string starts with a 1.459 + minus, the following rights are removed from any existing rights for 1.460 + the identifier. If the string does not start with a plus or minus, 1.461 + the rights replace any existing rights for the identifier. 1.462 + 1.463 + Note that an unrecognized right MUST cause the command to return the 1.464 + BAD response. In particular, the server MUST NOT silently ignore 1.465 + unrecognized rights. 1.466 + 1.467 + Example: C: A001 GETACL INBOX/Drafts 1.468 + S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswi 1.469 + S: A001 OK Getacl complete 1.470 + C: A002 SETACL INBOX/Drafts Chris +cda 1.471 + S: A002 OK Setacl complete 1.472 + C: A003 GETACL INBOX/Drafts 1.473 + S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswicdakxet 1.474 + S: A003 OK Getacl complete 1.475 + 1.476 + 1.477 + C: A035 SETACL INBOX/Drafts John lrQswicda 1.478 + S: A035 BAD Uppercase rights are not allowed 1.479 + 1.480 + 1.481 + C: A036 SETACL INBOX/Drafts John lrqswicda 1.482 + S: A036 BAD The q right is not supported 1.483 + 1.484 +3.2. DELETEACL Command 1.485 + 1.486 + Arguments: mailbox name 1.487 + identifier 1.488 + 1.489 + Data: no specific data for this command 1.490 + 1.491 + Result: OK - deleteacl completed 1.492 + NO - deleteacl failure: can't delete acl 1.493 + BAD - arguments invalid 1.494 + 1.495 + The DELETEACL command removes any <identifier,rights> pair for the 1.496 + specified identifier from the access control list for the specified 1.497 + mailbox. 1.498 + 1.499 + Example: C: B001 getacl INBOX 1.500 + S: * ACL INBOX Fred rwipslxetad -Fred wetd $team w 1.501 + S: B001 OK Getacl complete 1.502 + C: B002 DeleteAcl INBOX Fred 1.503 + S: B002 OK Deleteacl complete 1.504 + 1.505 + 1.506 + 1.507 + 1.508 + 1.509 +Melnikov Standards Track [Page 9] 1.510 + 1.511 +RFC 4314 IMAP ACL December 2005 1.512 + 1.513 + 1.514 + C: B003 GETACL INBOX 1.515 + S: * ACL INBOX -Fred wetd $team w 1.516 + S: B003 OK Getacl complete 1.517 + 1.518 +3.3. GETACL Command 1.519 + 1.520 + Arguments: mailbox name 1.521 + 1.522 + Data: untagged responses: ACL 1.523 + 1.524 + Result: OK - getacl completed 1.525 + NO - getacl failure: can't get acl 1.526 + BAD - arguments invalid 1.527 + 1.528 + The GETACL command returns the access control list for mailbox in an 1.529 + untagged ACL response. 1.530 + 1.531 + Some implementations MAY permit multiple forms of an identifier to 1.532 + reference the same IMAP account. Usually, such implementations will 1.533 + have a canonical form that is stored internally. An ACL response 1.534 + caused by a GETACL command MAY include a canonicalized form of the 1.535 + identifier that might be different from the one used in the 1.536 + corresponding SETACL command. 1.537 + 1.538 + Example: C: A002 GETACL INBOX 1.539 + S: * ACL INBOX Fred rwipsldexta 1.540 + S: A002 OK Getacl complete 1.541 + 1.542 +3.4. LISTRIGHTS Command 1.543 + 1.544 + Arguments: mailbox name 1.545 + identifier 1.546 + 1.547 + Data: untagged responses: LISTRIGHTS 1.548 + 1.549 + Result: OK - listrights completed 1.550 + NO - listrights failure: can't get rights list 1.551 + BAD - arguments invalid 1.552 + 1.553 + The LISTRIGHTS command takes a mailbox name and an identifier and 1.554 + returns information about what rights can be granted to the 1.555 + identifier in the ACL for the mailbox. 1.556 + 1.557 + Some implementations MAY permit multiple forms of an identifier to 1.558 + reference the same IMAP account. Usually, such implementations will 1.559 + have a canonical form that is stored internally. A LISTRIGHTS 1.560 + 1.561 + 1.562 + 1.563 + 1.564 + 1.565 +Melnikov Standards Track [Page 10] 1.566 + 1.567 +RFC 4314 IMAP ACL December 2005 1.568 + 1.569 + 1.570 + response caused by a LISTRIGHTS command MUST always return the same 1.571 + form of an identifier as specified by the client. This is to allow 1.572 + the client to correlate the response with the command. 1.573 + 1.574 + Example: C: a001 LISTRIGHTS ~/Mail/saved smith 1.575 + S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte 1.576 + S: a001 OK Listrights completed 1.577 + 1.578 + Example: C: a005 listrights archive/imap anyone 1.579 + S: * LISTRIGHTS archive.imap anyone "" 1.580 + l r s w i p k x t e c d a 0 1 2 3 4 5 6 7 8 9 1.581 + S: a005 Listrights successful 1.582 + 1.583 +3.5. MYRIGHTS Command 1.584 + 1.585 + Arguments: mailbox name 1.586 + 1.587 + Data: untagged responses: MYRIGHTS 1.588 + 1.589 + Result: OK - myrights completed 1.590 + NO - myrights failure: can't get rights 1.591 + BAD - arguments invalid 1.592 + 1.593 + The MYRIGHTS command returns the set of rights that the user has to 1.594 + mailbox in an untagged MYRIGHTS reply. 1.595 + 1.596 + Example: C: A003 MYRIGHTS INBOX 1.597 + S: * MYRIGHTS INBOX rwiptsldaex 1.598 + S: A003 OK Myrights complete 1.599 + 1.600 +3.6. ACL Response 1.601 + 1.602 + Data: mailbox name 1.603 + zero or more identifier rights pairs 1.604 + 1.605 + The ACL response occurs as a result of a GETACL command. The first 1.606 + string is the mailbox name for which this ACL applies. This is 1.607 + followed by zero or more pairs of strings; each pair contains the 1.608 + identifier for which the entry applies followed by the set of rights 1.609 + that the identifier has. 1.610 + 1.611 + Section 2.1.1 details additional server requirements related to 1.612 + handling of the virtual "d" and "c" rights. 1.613 + 1.614 + 1.615 + 1.616 + 1.617 + 1.618 + 1.619 + 1.620 + 1.621 +Melnikov Standards Track [Page 11] 1.622 + 1.623 +RFC 4314 IMAP ACL December 2005 1.624 + 1.625 + 1.626 +3.7. LISTRIGHTS Response 1.627 + 1.628 + Data: mailbox name 1.629 + identifier 1.630 + required rights 1.631 + list of optional rights 1.632 + 1.633 + The LISTRIGHTS response occurs as a result of a LISTRIGHTS command. 1.634 + The first two strings are the mailbox name and identifier for which 1.635 + this rights list applies. Following the identifier is a string 1.636 + containing the (possibly empty) set of rights the identifier will 1.637 + always be granted in the mailbox. 1.638 + 1.639 + Following this are zero or more strings each containing a set of 1.640 + rights the identifier can be granted in the mailbox. Rights 1.641 + mentioned in the same string are tied together. The server MUST 1.642 + either grant all tied rights to the identifier in the mailbox or 1.643 + grant none. Section 2.1.1 details additional server requirements 1.644 + related to handling of the virtual "d" and "c" rights. 1.645 + 1.646 + The same right MUST NOT be listed more than once in the LISTRIGHTS 1.647 + command. 1.648 + 1.649 +3.8. MYRIGHTS Response 1.650 + 1.651 + Data: mailbox name 1.652 + rights 1.653 + 1.654 + The MYRIGHTS response occurs as a result of a MYRIGHTS command. The 1.655 + first string is the mailbox name for which these rights apply. The 1.656 + second string is the set of rights that the client has. 1.657 + 1.658 + Section 2.1.1 details additional server requirements related to 1.659 + handling of the virtual "d" and "c" rights. 1.660 + 1.661 +4. Rights Required to Perform Different IMAP4rev1 Commands 1.662 + 1.663 + Before executing a command, an ACL-compliant server MUST check which 1.664 + rights are required to perform it. This section groups command by 1.665 + functions they perform and list the rights required. It also gives 1.666 + the detailed description of any special processing required. 1.667 + 1.668 + For the purpose of this section the UID counterpart of a command is 1.669 + considered to be the same command, e.g., both UID COPY and COPY 1.670 + commands require the same set of rights. 1.671 + 1.672 + 1.673 + 1.674 + 1.675 + 1.676 + 1.677 +Melnikov Standards Track [Page 12] 1.678 + 1.679 +RFC 4314 IMAP ACL December 2005 1.680 + 1.681 + 1.682 + The table below summarizes different rights or their combinations 1.683 + that are required in order to perform different IMAP operations. As 1.684 + it is not always possible to express complex right checking and 1.685 + interactions, the description after the table should be used as the 1.686 + primary reference. 1.687 + 1.688 + +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ 1.689 + |Operations\Rights | l | r | s | w | i | k | x | t | e | a |Any|Non| 1.690 + +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ 1.691 + | commands in authenticated state | 1.692 + +-------------------------------------------------------------------+ 1.693 + | LIST | + | | | | | | | | | | | | 1.694 + | SUBSCRIBE | * | | | | | | | | | | | * | 1.695 + | UNSUBSCRIBE | | | | | | | | | | | | + | 1.696 + | LSUB | * | | | | | | | | | | | * | 1.697 + |CREATE (for parent)| | | | | | + | | | | | | | 1.698 + | DELETE | | ? | | | | | + | ? | ? | | | | 1.699 + | RENAME | | | | | | + | + | | | | | | 1.700 + | SELECT/EXAMINE | | + | | | | | | | | | | | 1.701 + | STATUS | | + | | | | | | | | | | | 1.702 + | SETACL/DELETEACL | | | | | | | | | | + | | | 1.703 + | GETACL/LISTRIGHTS | | | | | | | | | | + | | | 1.704 + | MYRIGHTS | | | | | | | | | | | + | | 1.705 + | APPEND | | | ? | ? | + | | | ? | | | | | 1.706 + +-------------------------------------------------------------------+ 1.707 + | commands in selected state | 1.708 + +-------------------------------------------------------------------+ 1.709 + | COPY | | | ? | ? | + | | | ? | | | | | 1.710 + | EXPUNGE | | | | | | | | | + | | | | 1.711 + | CLOSE | | | | | | | | | ? | | | | 1.712 + | FETCH | | | ? | | | | | | | | | | 1.713 + | STORE flags | | | ? | ? | | | | ? | | | | | 1.714 + +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ 1.715 + 1.716 + Note: for all commands in the selected state, the "r" is implied, 1.717 + because it is required to SELECT/EXAMINE a mailbox. Servers are not 1.718 + required to check presence of the "r" right once a mailbox is 1.719 + successfully selected. 1.720 + 1.721 + Legend: 1.722 + + - The right is required 1.723 + * - Only one of the rights marked with * is required 1.724 + (see description below) 1.725 + ? - The right is OPTIONAL (see description below) 1.726 + "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is 1.727 + required 1.728 + "Non" - No rights required to perform the command 1.729 + 1.730 + 1.731 + 1.732 + 1.733 +Melnikov Standards Track [Page 13] 1.734 + 1.735 +RFC 4314 IMAP ACL December 2005 1.736 + 1.737 + 1.738 + Listing and subscribing/unsubscribing mailboxes: 1.739 + LIST - "l" right is required. However, unlike other commands 1.740 + (e.g., SELECT) the server MUST NOT return a NO response if it 1.741 + can't list a mailbox. 1.742 + Note that if the user has "l" right to a mailbox "A/B", but not to 1.743 + its parent mailbox "A", the LIST command should behave as if the 1.744 + mailbox "A" doesn't exist, for example: 1.745 + 1.746 + C: A777 LIST "" * 1.747 + S: * LIST (\NoInferiors) "/" "A/B" 1.748 + S: * LIST () "/" "C" 1.749 + S: * LIST (\NoInferiors) "/" "C/D" 1.750 + S: A777 OK LIST completed 1.751 + 1.752 + 1.753 + SUBSCRIBE - "l" right is required only if the server checks for 1.754 + mailbox existence when performing SUBSCRIBE. 1.755 + 1.756 + UNSUBSCRIBE - no rights required to perform this operation. 1.757 + 1.758 + LSUB - "l" right is required only if the server checks for mailbox 1.759 + existence when performing SUBSCRIBE. However, unlike other 1.760 + commands (e.g., SELECT) the server MUST NOT return a NO response 1.761 + if it can't list a subscribed mailbox. 1.762 + 1.763 + Mailbox management: 1.764 + CREATE - "k" right on a nearest existing parent mailbox. When a 1.765 + new mailbox is created, it SHOULD inherit the ACL from the parent 1.766 + mailbox (if one exists) in the defined hierarchy. 1.767 + 1.768 + DELETE - "x" right on the mailbox. Note that some servers don't 1.769 + allow to delete a non-empty mailbox. If this is the case, the 1.770 + user would also need "r", "e", and "t" rights, in order to open 1.771 + the mailbox and empty it. 1.772 + 1.773 + The DELETE command MUST delete the ACL associated with the deleted 1.774 + mailbox. 1.775 + 1.776 + RENAME - Moving a mailbox from one parent to another requires the 1.777 + "x" right on the mailbox itself and the "k" right for the new 1.778 + parent. For example, if the user wants to rename the mailbox 1.779 + named "A/B/C" to "D/E", the user must have the "x" right for the 1.780 + mailbox "A/B/C" and the "k" right for the mailbox "D". 1.781 + The RENAME command SHOULD NOT change the ACLs on the renamed 1.782 + mailbox and submailboxes. 1.783 + 1.784 + 1.785 + 1.786 + 1.787 + 1.788 + 1.789 +Melnikov Standards Track [Page 14] 1.790 + 1.791 +RFC 4314 IMAP ACL December 2005 1.792 + 1.793 + 1.794 + Copying or appending messages: 1.795 + Before performing a COPY/APPEND command, the server MUST check if 1.796 + the user has "i" right for the target mailbox. If the user 1.797 + doesn't have "i" right, the operation fails. Otherwise for each 1.798 + copied/appended message the server MUST check if the user has 1.799 + "t" right - when the message has \Deleted flag set 1.800 + "s" right - when the message has \Seen flag set 1.801 + "w" right - for all other message flags. 1.802 + Only when the user has a particular right are the corresponding 1.803 + flags stored for the newly created message. The server MUST NOT 1.804 + fail a COPY/APPEND if the user has no rights to set a particular 1.805 + flag. 1.806 + 1.807 + Example: C: A003 MYRIGHTS TargetMailbox 1.808 + S: * MYRIGHTS TargetMailbox rwis 1.809 + S: A003 OK Myrights complete 1.810 + 1.811 + C: A004 FETCH 1:3 (FLAGS) 1.812 + S: * 1 FETCH (FLAGS (\Draft \Deleted) 1.813 + S: * 2 FETCH (FLAGS (\Answered) 1.814 + S: * 3 FETCH (FLAGS ($Forwarded \Seen) 1.815 + S: A004 OK Fetch Completed 1.816 + 1.817 + C: A005 COPY 1:3 TargetMailbox 1.818 + S: A005 OK Copy completed 1.819 + 1.820 + C: A006 SELECT TargetMailbox 1.821 + ... 1.822 + S: A006 Select Completed 1.823 + 1.824 + Let's assume that the copied messages received message numbers 1.825 + 77:79. 1.826 + 1.827 + C: A007 FETCH 77:79 (FLAGS) 1.828 + S: * 77 FETCH (FLAGS (\Draft)) 1.829 + S: * 78 FETCH (FLAGS (\Answered)) 1.830 + S: * 79 FETCH (FLAGS ($Forwarded \Seen)) 1.831 + S: A007 OK Fetch Completed 1.832 + 1.833 + \Deleted flag was lost on COPY, as the user has no "t" right in 1.834 + the target mailbox. 1.835 + If the MYRIGHTS command with the tag A003 would have returned: 1.836 + 1.837 + S: * MYRIGHTS TargetMailbox rsti 1.838 + 1.839 + the response from the FETCH with the tag A007 would have been: 1.840 + 1.841 + C: A007 FETCH 77:79 (FLAGS) 1.842 + 1.843 + 1.844 + 1.845 +Melnikov Standards Track [Page 15] 1.846 + 1.847 +RFC 4314 IMAP ACL December 2005 1.848 + 1.849 + 1.850 + S: * 77 FETCH (FLAGS (\Deleted)) 1.851 + S: * 78 FETCH (FLAGS ()) 1.852 + S: * 79 FETCH (FLAGS (\Seen)) 1.853 + S: A007 OK Fetch Completed 1.854 + 1.855 + In the latter case, \Answered, $Forwarded, and \Draft flags were 1.856 + lost on COPY, as the user has no "w" right in the target mailbox. 1.857 + 1.858 + Expunging the selected mailbox: 1.859 + EXPUNGE - "e" right on the selected mailbox. 1.860 + 1.861 + CLOSE - "e" right on the selected mailbox. If the server is 1.862 + unable to expunge the mailbox because the user doesn't have the 1.863 + "e" right, the server MUST ignore the expunge request, close the 1.864 + mailbox, and return the tagged OK response. 1.865 + 1.866 + Fetch information about a mailbox and its messages: 1.867 + SELECT/EXAMINE/STATUS - "r" right on the mailbox. 1.868 + 1.869 + FETCH - A FETCH request that implies setting \Seen flag MUST NOT 1.870 + set it, if the current user doesn't have "s" right. 1.871 + 1.872 + Changing flags: 1.873 + STORE - the server MUST check if the user has 1.874 + "t" right - when the user modifies \Deleted flag 1.875 + "s" right - when the user modifies \Seen flag 1.876 + "w" right - for all other message flags. 1.877 + STORE operation SHOULD NOT fail if the user has rights to modify 1.878 + at least one flag specified in the STORE, as the tagged NO 1.879 + response to a STORE command is not handled very well by deployed 1.880 + clients. 1.881 + 1.882 + Changing ACLs: 1.883 + SETACL/DELETEACL - "a" right on the mailbox. 1.884 + 1.885 + Reading ACLs: 1.886 + GETACL - "a" right on the mailbox. 1.887 + 1.888 + MYRIGHTS - any of the following rights is required to perform the 1.889 + operation: "l", "r", "i", "k", "x", "a". 1.890 + 1.891 + LISTRIGHTS - "a" right on the mailbox. 1.892 + 1.893 + 1.894 + 1.895 + 1.896 + 1.897 + 1.898 + 1.899 + 1.900 + 1.901 +Melnikov Standards Track [Page 16] 1.902 + 1.903 +RFC 4314 IMAP ACL December 2005 1.904 + 1.905 + 1.906 +5. Other Considerations 1.907 + 1.908 +5.1. Additional Requirements and Implementation Notes 1.909 + 1.910 +5.1.1. Servers 1.911 + 1.912 + This document defines an additional capability that is used to 1.913 + announce the list of extra rights (excluding the ones defined in RFC 1.914 + 2086) supported by the server. The set of rights MUST include "t", 1.915 + "e", "x", and "k". Note that the extra rights can appear in any 1.916 + order. 1.917 + 1.918 + Example: C: 1 capability 1.919 + S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ 1.920 + ACL RIGHTS=texk 1.921 + S: 1 OK completed 1.922 + 1.923 + Any server implementing an ACL extension MUST accurately reflect the 1.924 + current user's rights in FLAGS and PERMANENTFLAGS responses. 1.925 + 1.926 + Example: C: A142 SELECT INBOX 1.927 + S: * 172 EXISTS 1.928 + S: * 1 RECENT 1.929 + S: * OK [UNSEEN 12] Message 12 is first unseen 1.930 + S: * OK [UIDVALIDITY 3857529045] UIDs valid 1.931 + S: * OK [UIDNEXT 4392] Predicted next UID 1.932 + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1.933 + S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L 1.934 + S: A142 OK [READ-WRITE] SELECT completed 1.935 + C: A143 MYRIGHTS INBOX 1.936 + S: * MYRIGHTS INBOX lrwis 1.937 + S: A143 OK completed 1.938 + 1.939 + Note that in order to get better performance the client MAY pipeline 1.940 + SELECT and MYRIGHTS commands: 1.941 + 1.942 + C: A142 SELECT INBOX 1.943 + C: A143 MYRIGHTS INBOX 1.944 + S: * 172 EXISTS 1.945 + S: * 1 RECENT 1.946 + S: * OK [UNSEEN 12] Message 12 is first unseen 1.947 + S: * OK [UIDVALIDITY 3857529045] UIDs valid 1.948 + S: * OK [UIDNEXT 4392] Predicted next UID 1.949 + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1.950 + S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L 1.951 + S: A142 OK [READ-WRITE] SELECT completed 1.952 + S: * MYRIGHTS INBOX lrwis 1.953 + S: A143 OK completed 1.954 + 1.955 + 1.956 + 1.957 +Melnikov Standards Track [Page 17] 1.958 + 1.959 +RFC 4314 IMAP ACL December 2005 1.960 + 1.961 + 1.962 + Servers MAY cache the rights a user has on a mailbox when the mailbox 1.963 + is selected, so that if a client's rights on a mailbox are changed 1.964 + with SETACL or DELETEACL, commands specific to the selected state 1.965 + (e.g., STORE, EXPUNGE) might not reflect the changed rights until the 1.966 + mailbox is re-selected. If the server checks the rights on each 1.967 + command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if 1.968 + they have changed. If such server detects that the user no longer 1.969 + has read access to the mailbox, it MAY send an untagged BYE response 1.970 + and close connection. It MAY also refuse to execute all commands 1.971 + specific to the selected state until the mailbox is closed; however, 1.972 + server implementors should note that most clients don't handle NO 1.973 + responses very well. 1.974 + 1.975 + An ACL server MAY modify one or more ACLs for one or more identifiers 1.976 + as a side effect of modifying the ACL specified in a 1.977 + SETACL/DELETEACL. If the server does that, it MUST send untagged ACL 1.978 + response(s) to notify the client about the changes made. 1.979 + 1.980 + An ACL server implementation MUST treat received ACL modification 1.981 + commands as a possible ambiguity with respect to subsequent commands 1.982 + affected by the ACL, as described in Section 5.5 of [IMAP4]. Hence a 1.983 + pipeline SETACL + MYRIGHTS is an ambiguity with respect to the 1.984 + server, meaning that the server must execute the SETACL command to 1.985 + completion before the MYRIGHTS. However, clients are permitted to 1.986 + send such a pipeline. 1.987 + 1.988 +5.1.2. Clients 1.989 + 1.990 + The following requirement is put on clients in order to allow for 1.991 + future extensibility. A client implementation that allows a user to 1.992 + read and update ACLs MUST preserve unrecognized rights that it 1.993 + doesn't allow the user to change. That is, if the client 1.994 + 1.995 + 1) can read ACLs 1.996 + and 1.997 + 2) can update ACLs 1.998 + but 1.999 + 3) doesn't allow the user to change the rights the client doesn't 1.1000 + recognize, then it MUST preserve unrecognized rights. 1.1001 + 1.1002 + Otherwise the client could risk unintentionally removing permissions 1.1003 + it doesn't understand. 1.1004 + 1.1005 + 1.1006 + 1.1007 + 1.1008 + 1.1009 + 1.1010 + 1.1011 + 1.1012 + 1.1013 +Melnikov Standards Track [Page 18] 1.1014 + 1.1015 +RFC 4314 IMAP ACL December 2005 1.1016 + 1.1017 + 1.1018 +5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes 1.1019 + 1.1020 + A particular ACL server implementation MAY allow "shared multiuser 1.1021 + access" to some mailboxes. "Shared multiuser access" to a mailbox 1.1022 + means that multiple different users are able to access the same 1.1023 + mailbox, if they have proper access rights. "Shared multiuser 1.1024 + access" to the mailbox doesn't mean that the ACL for the mailbox is 1.1025 + currently set to allow access by multiple users. Let's denote a 1.1026 + "shared multiuser write access" as a "shared multiuser access" when a 1.1027 + user can be granted flag modification rights (any of "w", "s", or 1.1028 + "t"). 1.1029 + 1.1030 + Section 4 describes which rights are required for modifying different 1.1031 + flags. 1.1032 + 1.1033 + If the ACL server implements some flags as shared for a mailbox 1.1034 + (i.e., the ACL for the mailbox MAY be set up so that changes to those 1.1035 + flags are visible to another user), let's call the set of rights 1.1036 + associated with these flags (as described in Section 4) for that 1.1037 + mailbox collectively as "shared flag rights". Note that the "shared 1.1038 + flag rights" set MAY be different for different mailboxes. 1.1039 + 1.1040 + If the server doesn't support "shared multiuser write access" to a 1.1041 + mailbox or doesn't implement shared flags on the mailbox, "shared 1.1042 + flag rights" for the mailbox is defined to be the empty set. 1.1043 + 1.1044 + Example 1: Mailbox "banan" allows "shared multiuser write access" and 1.1045 + implements flags \Deleted, \Answered, and $MDNSent as 1.1046 + shared flags. "Shared flag rights" for the mailbox "banan" 1.1047 + is a set containing flags "t" (because system flag 1.1048 + \Deleted requires "t" right) and "w" (because both 1.1049 + \Answered and $MDNSent require "w" right). 1.1050 + 1.1051 + Example 2: Mailbox "apple" allows "shared multiuser write access" and 1.1052 + implements \Seen system flag as shared flag. "Shared flag 1.1053 + rights" for the mailbox "apple" contains "s" right 1.1054 + because system flag \Seen requires "s" right. 1.1055 + 1.1056 + Example 3: Mailbox "pear" allows "shared multiuser write access" and 1.1057 + implements flags \Seen, \Draft as shared flags. "Shared 1.1058 + flag rights" for the mailbox "apple" is a set containing 1.1059 + flags "s" (because system flag \Seen requires "s" right) 1.1060 + and "w" (because system flag \Draft requires "w" right). 1.1061 + 1.1062 + The server MUST include a READ-ONLY response code in the tagged OK 1.1063 + response to a SELECT command if none of the following rights is 1.1064 + granted to the current user: 1.1065 + 1.1066 + 1.1067 + 1.1068 + 1.1069 +Melnikov Standards Track [Page 19] 1.1070 + 1.1071 +RFC 4314 IMAP ACL December 2005 1.1072 + 1.1073 + 1.1074 + "i", "e", and "shared flag rights"(***). 1.1075 + 1.1076 + The server SHOULD include a READ-WRITE response code in the tagged OK 1.1077 + response if at least one of the "i", "e", or "shared flag 1.1078 + rights"(***) is granted to the current user. 1.1079 + 1.1080 + (***) Note that a future extension to this document can extend the 1.1081 + list of rights that causes the server to return the READ-WRITE 1.1082 + response code. 1.1083 + 1.1084 + Example 1 (continued): The user that has "lrs" rights for the mailbox 1.1085 + "banan". The server returns READ-ONLY 1.1086 + response code on SELECT, as none of "iewt" 1.1087 + rights is granted to the user. 1.1088 + 1.1089 + Example 2 (continued): The user that has "rit" rights for the mailbox 1.1090 + "apple". The server returns READ-WRITE 1.1091 + response code on SELECT, as the user has "i" 1.1092 + right. 1.1093 + 1.1094 + Example 3 (continued): The user that has "rset" rights for the 1.1095 + mailbox "pear". The server returns READ-WRITE 1.1096 + response code on SELECT, as the user has "e" 1.1097 + and "s" rights. 1.1098 + 1.1099 +6. Security Considerations 1.1100 + 1.1101 + An implementation MUST make sure the ACL commands themselves do not 1.1102 + give information about mailboxes with appropriately restricted ACLs. 1.1103 + For example, when a user agent executes a GETACL command on a mailbox 1.1104 + that the user has no permission to LIST, the server would respond to 1.1105 + that request with the same error that would be used if the mailbox 1.1106 + did not exist, thus revealing no existence information, much less the 1.1107 + mailbox's ACL. 1.1108 + 1.1109 + IMAP clients implementing ACL that are able to modify ACLs SHOULD 1.1110 + warn a user that wants to give full access (or even just the "a" 1.1111 + right) to the special identifier "anyone". 1.1112 + 1.1113 + This document relies on [SASLprep] to describe steps required to 1.1114 + perform identifier canonicalization (preparation). The preparation 1.1115 + algorithm in SASLprep was specifically designed such that its output 1.1116 + is canonical, and it is well-formed. However, due to an anomaly 1.1117 + [PR29] in the specification of Unicode normalization, canonical 1.1118 + equivalence is not guaranteed for a select few character sequences. 1.1119 + Identifiers prepared with SASLprep can be stored and returned by an 1.1120 + ACL server. The anomaly affects ACL manipulation and evaluation of 1.1121 + identifiers containing the selected character sequences. These 1.1122 + 1.1123 + 1.1124 + 1.1125 +Melnikov Standards Track [Page 20] 1.1126 + 1.1127 +RFC 4314 IMAP ACL December 2005 1.1128 + 1.1129 + 1.1130 + sequences, however, do not appear in well-formed text. In order to 1.1131 + address this problem, an ACL server MAY reject identifiers containing 1.1132 + sequences described in [PR29] by sending the tagged BAD response. 1.1133 + This is in addition to the requirement to reject identifiers that 1.1134 + fail SASLprep preparation as described in Section 3. 1.1135 + 1.1136 + Other security considerations described in [IMAP4] are relevant to 1.1137 + this document. In particular, ACL information is sent in the clear 1.1138 + over the network unless confidentiality protection is negotiated. 1.1139 + 1.1140 + This can be accomplished either by the use of STARTTLS, negotiated 1.1141 + privacy protection in the AUTHENTICATE command, or some other 1.1142 + protection mechanism. 1.1143 + 1.1144 +7. Formal Syntax 1.1145 + 1.1146 + Formal syntax is defined using ABNF [ABNF], extending the ABNF rules 1.1147 + in Section 9 of [IMAP4]. Elements not defined here can be found in 1.1148 + [ABNF] and [IMAP4]. 1.1149 + 1.1150 + Except as noted otherwise, all alphabetic characters are case 1.1151 + insensitive. The use of uppercase or lowercase characters to define 1.1152 + token strings is for editorial clarity only. Implementations MUST 1.1153 + accept these strings in a case-insensitive fashion. 1.1154 + 1.1155 + LOWER-ALPHA = %x61-7A ;; a-z 1.1156 + 1.1157 + acl-data = "ACL" SP mailbox *(SP identifier SP 1.1158 + rights) 1.1159 + 1.1160 + capability =/ rights-capa 1.1161 + ;;capability is defined in [IMAP4] 1.1162 + 1.1163 + command-auth =/ setacl / deleteacl / getacl / 1.1164 + listrights / myrights 1.1165 + ;;command-auth is defined in [IMAP4] 1.1166 + 1.1167 + deleteacl = "DELETEACL" SP mailbox SP identifier 1.1168 + 1.1169 + getacl = "GETACL" SP mailbox 1.1170 + 1.1171 + identifier = astring 1.1172 + 1.1173 + listrights = "LISTRIGHTS" SP mailbox SP identifier 1.1174 + 1.1175 + listrights-data = "LISTRIGHTS" SP mailbox SP identifier 1.1176 + SP rights *(SP rights) 1.1177 + 1.1178 + 1.1179 + 1.1180 + 1.1181 +Melnikov Standards Track [Page 21] 1.1182 + 1.1183 +RFC 4314 IMAP ACL December 2005 1.1184 + 1.1185 + 1.1186 + mailbox-data =/ acl-data / listrights-data / myrights-data 1.1187 + ;;mailbox-data is defined in [IMAP4] 1.1188 + 1.1189 + mod-rights = astring 1.1190 + ;; +rights to add, -rights to remove 1.1191 + ;; rights to replace 1.1192 + 1.1193 + myrights = "MYRIGHTS" SP mailbox 1.1194 + 1.1195 + myrights-data = "MYRIGHTS" SP mailbox SP rights 1.1196 + 1.1197 + new-rights = 1*LOWER-ALPHA 1.1198 + ;; MUST include "t", "e", "x", and "k". 1.1199 + ;; MUST NOT include standard rights listed 1.1200 + ;; in section 2.2 1.1201 + 1.1202 + rights = astring 1.1203 + ;; only lowercase ASCII letters and digits 1.1204 + ;; are allowed. 1.1205 + 1.1206 + rights-capa = "RIGHTS=" new-rights 1.1207 + ;; RIGHTS=... capability 1.1208 + 1.1209 + setacl = "SETACL" SP mailbox SP identifier 1.1210 + SP mod-rights 1.1211 + 1.1212 +8. IANA Considerations 1.1213 + 1.1214 + IMAP4 capabilities are registered by publishing a standards-track or 1.1215 + IESG-approved experimental RFC. The registry is currently located 1.1216 + at: 1.1217 + 1.1218 + http://www.iana.org/assignments/imap4-capabilities 1.1219 + 1.1220 + This document defines the RIGHTS= IMAP capability. IANA has added 1.1221 + this capability to the registry. 1.1222 + 1.1223 +9. Internationalization Considerations 1.1224 + 1.1225 + Section 3 states requirements on servers regarding 1.1226 + internationalization of identifiers. 1.1227 + 1.1228 + 1.1229 + 1.1230 + 1.1231 + 1.1232 + 1.1233 + 1.1234 + 1.1235 + 1.1236 + 1.1237 +Melnikov Standards Track [Page 22] 1.1238 + 1.1239 +RFC 4314 IMAP ACL December 2005 1.1240 + 1.1241 + 1.1242 +Appendix A. Changes since RFC 2086 1.1243 + 1.1244 + 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 1.1245 + 2. Specified that mailbox deletion is controlled by the "x" right 1.1246 + and EXPUNGE is controlled by the "e" right. 1.1247 + 3. Added the "t" right that controls STORE \Deleted. Redefined the 1.1248 + "d" right to be a macro for "e", "t", and possibly "x". 1.1249 + 4. Added the "k" right that controls CREATE. Redefined the "c" 1.1250 + right to be a macro for "k" and possibly "x". 1.1251 + 5. Specified that the "a" right also controls DELETEACL. 1.1252 + 6. Specified that the "r" right also controls STATUS. 1.1253 + 7. Removed the requirement to check the "r" right for CHECK, SEARCH 1.1254 + and FETCH, as this is required for SELECT/EXAMINE to be 1.1255 + successful. 1.1256 + 8. LISTRIGHTS requires the "a" right on the mailbox (same as 1.1257 + SETACL). 1.1258 + 9. Deleted "PARTIAL", this is a deprecated feature of RFC 1730. 1.1259 + 10. Specified that the "w" right controls setting flags other than 1.1260 + \Seen and \Deleted on APPEND. Also specified that the "s" right 1.1261 + controls the \Seen flag and that the "t" right controls the 1.1262 + \Deleted flag. 1.1263 + 11. Specified that SUBSCRIBE is NOT allowed with the "r" right. 1.1264 + 12. Specified that the "l" right controls SUBSCRIBE. 1.1265 + 13. GETACL is NOT allowed with the "r" right, even though there are 1.1266 + several implementations that allows that. If a user only has 1.1267 + "r" right, GETACL can disclose information about identifiers 1.1268 + existing on the mail system. 1.1269 + 14. Clarified that RENAME requires the "k" right for the new parent 1.1270 + and the "x" right for the old name. 1.1271 + 15. Added new section that describes which rights are required 1.1272 + and/or checked when performing various IMAP commands. 1.1273 + 16. Added mail client security considerations when dealing with 1.1274 + special identifier "anyone". 1.1275 + 17. Clarified that negative rights are not the same as DELETEACL. 1.1276 + 18. Added "Compatibility with RFC 2086" section. 1.1277 + 19. Added section about mapping of ACL rights to READ-WRITE and 1.1278 + READ-ONLY response codes. 1.1279 + 20. Changed BNF to ABNF. 1.1280 + 21. Added "Implementation Notes" section. 1.1281 + 22. Updated "References" section. 1.1282 + 23. Added more examples. 1.1283 + 24. Clarified when the virtual "c" and "d" rights are returned in 1.1284 + ACL, MYRIGHTS, and LISTRIGHTS responses. 1.1285 + 1.1286 + 1.1287 + 1.1288 + 1.1289 + 1.1290 + 1.1291 + 1.1292 + 1.1293 +Melnikov Standards Track [Page 23] 1.1294 + 1.1295 +RFC 4314 IMAP ACL December 2005 1.1296 + 1.1297 + 1.1298 +Appendix B. Compatibility with RFC 2086 1.1299 + 1.1300 + This non-normative section gives guidelines as to how an existing RFC 1.1301 + 2086 server implementation may be updated to comply with this 1.1302 + document. 1.1303 + 1.1304 + This document splits the "d" right into several new different rights: 1.1305 + "t", "e", and possibly "x" (see Section 2.1.1 for more details). The 1.1306 + "d" right remains for backward-compatibility, but it is a virtual 1.1307 + right. There are two approaches for RFC 2086 server implementors to 1.1308 + handle the "d" right and the new rights that have replaced it: 1.1309 + 1.1310 + a. Tie "t", "e" (and possibly "x) together - almost no changes. 1.1311 + b. Implement separate "x", "t" and "e". Return the "d" right in a 1.1312 + MYRIGHTS response or an ACL response containing ACL information 1.1313 + when any of the "t", "e" (and "x") is granted. 1.1314 + 1.1315 + In a similar manner this document splits the "c" right into several 1.1316 + new different rights: "k" and possibly "x" (see Section 2.1.1 for 1.1317 + more details). The "c" right remains for backwards-compatibility but 1.1318 + it is a virtual right. Again, RFC 2086 server implementors can 1.1319 + choose to tie rights or to implement separate rights, as described 1.1320 + above. 1.1321 + 1.1322 + Also check Sections 5.1.1 and 5.1.2, as well as Appendix A, to see 1.1323 + other changes required. Server implementors should check which 1.1324 + rights are required to invoke different IMAP4 commands as described 1.1325 + in Section 4. 1.1326 + 1.1327 +Appendix C. Known Deficiencies 1.1328 + 1.1329 + This specification has some known deficiencies including: 1.1330 + 1.1331 + 1. This is inadequate to provide complete read-write access to 1.1332 + mailboxes protected by Unix-style rights bits because there is no 1.1333 + equivalent to "chown" and "chgrp" commands nor is there a good 1.1334 + way to discover such limitations are present. 1.1335 + 2. Because this extension leaves the specific semantics of how 1.1336 + rights are combined by the server as implementation defined, the 1.1337 + ability to build a user-friendly interface is limited. 1.1338 + 3. Users, groups, and special identifiers (e.g., anyone) exist in 1.1339 + the same namespace. 1.1340 + 1.1341 + The work-in-progress "ACL2" extension is intended to redesign this 1.1342 + extension to address these deficiencies without the constraint of 1.1343 + backward-compatibility and may eventually supercede this facility. 1.1344 + 1.1345 + 1.1346 + 1.1347 + 1.1348 + 1.1349 +Melnikov Standards Track [Page 24] 1.1350 + 1.1351 +RFC 4314 IMAP ACL December 2005 1.1352 + 1.1353 + 1.1354 + However, RFC 2086 is deployed in multiple implementations so this 1.1355 + intermediate step, which fixes the straightforward deficiencies in a 1.1356 + backward-compatible fashion, is considered worthwhile. 1.1357 + 1.1358 +Appendix D. Acknowledgements 1.1359 + 1.1360 + This document is a revision of RFC 2086 written by John G. Myers. 1.1361 + 1.1362 + Editor appreciates comments received from Mark Crispin, Chris Newman, 1.1363 + Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole, 1.1364 + Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie 1.1365 + Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon 1.1366 + Nerenberg, Lisa Dusseault, Arnt Gulbrandsen, and other participants 1.1367 + of the IMAPEXT working group. 1.1368 + 1.1369 +Normative References 1.1370 + 1.1371 + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1.1372 + Requirement Levels", BCP 14, RFC 2119, March 1997. 1.1373 + 1.1374 + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1.1375 + Specifications: ABNF", RFC 4234, October 2005. 1.1376 + 1.1377 + [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1.1378 + 4rev1", RFC 3501, March 2003. 1.1379 + 1.1380 + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 1.1381 + 10646", STD 63, RFC 3629, November 2003. 1.1382 + 1.1383 + [Stringprep] Hoffman, P. and M. Blanchet, "Preparation of 1.1384 + Internationalized Strings ("stringprep")", RFC 3454, 1.1385 + December 2002. 1.1386 + 1.1387 + [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User 1.1388 + Names and Passwords", RFC 4013, February 2005. 1.1389 + 1.1390 +Informative References 1.1391 + 1.1392 + [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, 1.1393 + January 1997. 1.1394 + 1.1395 + [PR29] "Public Review Issue #29: Normalization Issue", 1.1396 + February 2004, 1.1397 + <http://www.unicode.org/review/pr-29.html>. 1.1398 + 1.1399 + 1.1400 + 1.1401 + 1.1402 + 1.1403 + 1.1404 + 1.1405 +Melnikov Standards Track [Page 25] 1.1406 + 1.1407 +RFC 4314 IMAP ACL December 2005 1.1408 + 1.1409 + 1.1410 +Author's Address 1.1411 + 1.1412 + Alexey Melnikov 1.1413 + Isode Ltd. 1.1414 + 5 Castle Business Village 1.1415 + 36 Station Road 1.1416 + Hampton, Middlesex TW12 2BX 1.1417 + GB 1.1418 + 1.1419 + EMail: alexey.melnikov@isode.com 1.1420 + 1.1421 + 1.1422 + 1.1423 + 1.1424 + 1.1425 + 1.1426 + 1.1427 + 1.1428 + 1.1429 + 1.1430 + 1.1431 + 1.1432 + 1.1433 + 1.1434 + 1.1435 + 1.1436 + 1.1437 + 1.1438 + 1.1439 + 1.1440 + 1.1441 + 1.1442 + 1.1443 + 1.1444 + 1.1445 + 1.1446 + 1.1447 + 1.1448 + 1.1449 + 1.1450 + 1.1451 + 1.1452 + 1.1453 + 1.1454 + 1.1455 + 1.1456 + 1.1457 + 1.1458 + 1.1459 + 1.1460 + 1.1461 +Melnikov Standards Track [Page 26] 1.1462 + 1.1463 +RFC 4314 IMAP ACL December 2005 1.1464 + 1.1465 + 1.1466 +Full Copyright Statement 1.1467 + 1.1468 + Copyright (C) The Internet Society (2005). 1.1469 + 1.1470 + This document is subject to the rights, licenses and restrictions 1.1471 + contained in BCP 78, and except as set forth therein, the authors 1.1472 + retain all their rights. 1.1473 + 1.1474 + This document and the information contained herein are provided on an 1.1475 + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1.1476 + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1.1477 + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1.1478 + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1.1479 + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1.1480 + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1.1481 + 1.1482 +Intellectual Property 1.1483 + 1.1484 + The IETF takes no position regarding the validity or scope of any 1.1485 + Intellectual Property Rights or other rights that might be claimed to 1.1486 + pertain to the implementation or use of the technology described in 1.1487 + this document or the extent to which any license under such rights 1.1488 + might or might not be available; nor does it represent that it has 1.1489 + made any independent effort to identify any such rights. Information 1.1490 + on the procedures with respect to rights in RFC documents can be 1.1491 + found in BCP 78 and BCP 79. 1.1492 + 1.1493 + Copies of IPR disclosures made to the IETF Secretariat and any 1.1494 + assurances of licenses to be made available, or the result of an 1.1495 + attempt made to obtain a general license or permission for the use of 1.1496 + such proprietary rights by implementers or users of this 1.1497 + specification can be obtained from the IETF on-line IPR repository at 1.1498 + http://www.ietf.org/ipr. 1.1499 + 1.1500 + The IETF invites any interested party to bring to its attention any 1.1501 + copyrights, patents or patent applications, or other proprietary 1.1502 + rights that may cover technology that may be required to implement 1.1503 + this standard. Please address the information to the IETF at ietf- 1.1504 + ipr@ietf.org. 1.1505 + 1.1506 +Acknowledgement 1.1507 + 1.1508 + Funding for the RFC Editor function is currently provided by the 1.1509 + Internet Society. 1.1510 + 1.1511 + 1.1512 + 1.1513 + 1.1514 + 1.1515 + 1.1516 + 1.1517 +Melnikov Standards Track [Page 27] 1.1518 +