idnits 2.17.1 draft-ietf-imapext-2086upd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 915. -- Found old boilerplate from RFC 3978, Section 5.5 on line 951. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1121 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 160 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7003 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'StringPrep' is mentioned on line 304, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 705, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 706, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 707, but not defined == Unused Reference: 'Stringprep' is defined on line 892, but no explicit reference was found in the text == Unused Reference: 'RFC2086' is defined on line 900, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 3454 (ref. 'Stringprep') (Obsoleted by RFC 7564) -- No information found for draft-ietf-sasl-saslprep-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLprep' -- Obsolete informational reference (is this intentional?): RFC 2086 (Obsoleted by RFC 4314) Summary: 16 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAPEXT Working Group A. Melnikov 2 Internet Draft Editor 3 Document: draft-ietf-imapext-2086upd-03.txt February 2005 4 Updates: <<3501?>> 5 Obsoletes: 2086 6 Expires: August 2005 8 IMAP4 ACL extension 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, or 14 will be disclosed, and any of which I become aware will be disclosed, 15 in accordance with RFC 3668. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its Areas, and its Working Groups. Note that 19 other groups may also distribute working documents as Internet 20 Drafts. Internet Drafts are draft documents valid for a maximum of 21 six months. Internet Drafts may be updated, replaced, or obsoleted 22 by other documents at any time. It is not appropriate to use 23 Internet Drafts as reference material or to cite them other than as 24 ``work in progress''. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 33 munnari.oz.au. 35 A revised version of this draft document will be submitted to the RFC 36 editor as a Proposed Standard for the Internet Community. Discussion 37 and suggestions for improvement are requested. Distribution of this 38 draft is unlimited. 40 Abstract 42 The ACL (Access Control List) extension (RFC 2086) of the Internet 43 Message Access Protocol (IMAP4rev1) permits mailbox access control 44 lists to be retrieved and manipulated through the IMAP protocol. 46 This document is a revision of the RFC 2086. It defines several new 47 access control rights and clarifies which rights are required for 48 different IMAP commands. 50 1. Conventions Used in this Document 52 In examples, "C:" and "S:" indicate lines sent by the client and 53 server respectively. 55 In all examples "/" character is used as hierarchy separator. 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 61 2. Introduction and Overview 63 The ACL (Access Control List) extension of the Internet Message Access 64 Protocol [IMAP4] permits mailbox access control lists to be retrieved 65 and manipulated through the IMAP protocol. 67 This document is a revision of the RFC 2086. It tries to clarify 68 different ambiguities in the RFC 2086, in particular use of UTF-8 69 [UTF-8] in identifiers, which rights are required for different IMAP4 70 commands; how READ-WRITE/READ-ONLY response codes are related to ACL. 72 3. Access Control 74 The ACL extension is present in any IMAP4 implementation which 75 returns "ACL" as one of the supported capabilities to the CAPABILITY 76 command. 78 A server implementation conformant to this document MUST also return 79 rights (see below) not defined in section 3.2 in the "RIGHTS=" 80 capability. 82 An access control list is a set of pairs. 83 An ACL applies to a mailbox name. 85 Identifier is a UTF-8 [UTF-8] string. The identifier "anyone" is reserved 86 to refer to the universal identity (all authentications, including 87 anonymous). All user name strings accepted by the LOGIN or 88 AUTHENTICATE commands to authenticate to the IMAP server are reserved 89 as identifiers for the corresponding users. Identifiers starting with 90 a dash ("-") are reserved for "negative rights", described below. 91 All other identifier strings are interpreted in an implementation- 92 defined manner. 94 Rights is a string listing a (possibly empty) set of alphanumeric 95 characters, each character listing a set of operations which is being 96 controlled. Lowercase letters are reserved for "standard" rights, 97 listed in section 3.1. (Note that for compatibility with deployed clients 98 and servers uppercase rights are not allowed). The set of 99 standard rights may only be extended by a standards-track document. 100 Digits are reserved for implementation or site defined rights. 102 An implementation may tie rights together or may force rights to 103 always or never be granted to particular identifiers. For example, 104 in an implementation that uses UNIX mode bits, the rights "swite" are 105 tied, the "a" right is always granted to the owner of a mailbox and 106 is never granted to another user. If rights are tied in an 107 implementation, the implementation must be conservative in granting 108 rights in response to SETACL commands--unless all rights in a tied 109 set are specified, none of that set should be included in the ACL 110 entry for that identifier. A client may discover the set of rights 111 which may be granted to a given identifier in the ACL for a given 112 mailbox name by using the LISTRIGHTS command. 114 It is possible for multiple identifiers in an access control list to 115 apply to a given user (or other authentication identity). For 116 example, an ACL may include rights to be granted to the identifier 117 matching the user, one or more implementation-defined identifiers 118 matching groups which include the user, and/or the identifier 119 "anyone". How these rights are combined to determine the user's 120 access is implementation-defined. An implementation may choose, for 121 example, to use the union of the rights granted to the applicable 122 identifiers. An implementation may instead choose, for example, to 123 only use those rights granted to the most specific identifier present 124 in the ACL. A client may determine the set of rights granted to the 125 logged-in user for a given mailbox name by using the MYRIGHTS command. 127 When an identifier in an ACL starts with a dash ("-"), that indicates 128 that associated rights are to be removed from the identifier that is 129 prefixed by the dash. This is referred to as a "negative right". 130 This differs from DELETEACL in that a negative right is added to the 131 ACL, and is a part of the calculation of the rights. 133 Let's assume that an identifier "fred" refers to a user with login "fred". 134 If the identifier "-fred" is granted the "w" right, 135 that indicates that the "w" right is to be removed from users matching 136 the identifier "fred", even though the user "fred" might have 137 the "w" right as a consequence of some other identifier in the ACL. 138 A DELETEACL of "fred" simply deletes the identifier "fred" 139 from the ACL; it does not affect any rights that the user "fred" 140 may get from another entry in the ACL, in particular it doesn't affect 141 rights granted to the identifier "-fred". 143 Server implementations are not required to support "negative right" 144 identifiers. 146 3.1. Standard rights 148 The currently defined standard rights are (note that the list below 149 doesn't list all commands that use a particular right): 151 l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox) 152 r - read (SELECT the mailbox, perform STATUS) 153 s - keep seen/unseen information across sessions (set or clear \SEEN flag 154 via STORE, APPEND or COPY) 155 w - write (set or clear flags other than \SEEN and \DELETED via STORE, 156 APPEND or COPY) 157 i - insert (perform APPEND, COPY into mailbox) 158 p - post (send mail to submission address for mailbox, 159 not enforced by IMAP4 itself) 160 k - create mailboxes (CREATE new sub-mailboxes in any 161 implementation-defined hierarchy, parent mailbox for the new 162 mailbox name in RENAME) 163 x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) 164 t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag 165 during APPEND/COPY) 166 e - perform EXPUNGE and expunge as a part of CLOSE. 167 a - administer (perform SETACL/DELETEACL/GETACL) 169 3.1.1. Obsolete rights 171 Due to ambiguity in RFC 2086 some existing RFC 2086 server implementations 172 use the "c" right to control the DELETE command. Others chose to use the 173 "d" right to control the DELETE command. 174 For the former group, let's define the "create" right as union of the "k" 175 and "x" rights, and the "delete" right as union of the "e" and "t" rights. 176 For the latter group, let's define the "create" rights as a synonym to the 177 "k" right, and the "delete" right as union of the "e", "t" and "x" rights. 179 For compatibility with RFC 2086 this section defines two virtual rights 180 "d" and "c". 182 If a client includes the "d" right in a rights list, then it MUST be 183 treated as if the client had included every member of the "delete" right. 184 (It is not an error for a client to specify both the "d" right and 185 one or more members of the "delete" right, but the effect is no different 186 than if just the "d" right or all members of the "delete" right had been 187 specified). 189 When any of the "delete" member rights is set in a list of 190 rights, the server MUST also include the "d" right when returning 191 the list in a MYRIGHTS or ACL response. This is so to enable older clients 192 conforming to RFC 2086 to work with newer servers. (*) 194 Example: C: A001 SETACL INBOX.Drafts David lrswida 195 S: A001 OK Setacl complete 197 The client has specified the "d" right in the SETACL command above and it 198 expands to "et" on the server: 200 C: A002 GETACL INBOX.Drafts 201 S: * ACL INBOX Fred rwipslxetda David lrswideta 202 S: A002 OK Getacl complete 204 If the authentication identifier specified in the LISTRIGHTS command can be 205 granted any of the "delete" member rights to access a mailbox, then the server 206 MUST include the "d" right in the corresponding LISTRIGHTS response. (*) 207 If the member rights aren't tied to non-member rights, then the "d" right 208 is returned by itself in the LISTRIGHTS response. If any of the member rights 209 needs to be tied to one (or more) non-member right, then the "d" right and all 210 of the member rights need to be tied to the same non-member right(s) (**). 212 If a client includes the "c" right in a rights list, then it MUST be 213 treated as if the client had included every member of the "create" right. 214 (It is not an error for a client to specify both the "c" right and 215 one or more members of the "create" right, but the effect is no different 216 than if just the "c" right or all members of the "create" right had been 217 specified). 219 When any of the "create" member rights is set in a list of 220 rights, the server MUST also include the "c" right when returning 221 the list in a MYRIGHTS or ACL response. This is so to enable older clients 222 conforming to RFC 2086 to work with newer servers. (*) 224 Example: C: A003 SETACL INBOX.Drafts Byron lrswikda 225 S: A001 OK Setacl complete 226 C: A002 GETACL INBOX.Drafts 227 S: * ACL INBOX Fred rwipslxeta Byron lrswikcdeta 228 S: A002 OK Getacl complete 230 The client has specified the "d" right in the SETACL command above and it 231 expands to "et" on the server: As the client has specified the "k" right 232 (which is a member of the "c" right), the server also returns the "c" right. 234 If the authentication identifier specified in the LISTRIGHTS command can be 235 granted any of the "create" member rights to access a mailbox, then the server 236 MUST include the "c" right in the corresponding LISTRIGHTS response. (*) 237 If the member rights aren't tied to non-member rights, then the "c" right 238 is returned by itself in the LISTRIGHTS response. If any of the member rights 239 needs to be tied to one (or more) non-member right, then the "c" right and all 240 of the member rights need to be tied to the same non-member right(s) (**). 242 Example: The server that ties the rights as follows 244 lr s w i p k x t 246 and c=k 248 will return: 250 S: * LISTRIGHTS archive.imap anyone "" lr s w i p k x t c d 252 Example: The server that ties the rights as follows 254 lr s w i p k xte 256 and c=k 258 will return: 260 S: * LISTRIGHTS archive.imap anyone "" lr s w i p k xte c d 262 Example: The server that ties the rights as follows 264 lr s w i p k x te 266 and c=k 268 will return: 270 S: * LISTRIGHTS archive.imap anyone "" lr s w i p k c x te d 272 Example: The server that ties the rights as follows 274 lr swte i p k x 276 and c=kx 278 will return: 280 S: * LISTRIGHTS archive.imap anyone "" lr swted i p k x c 282 (*) Clients conforming to this document MUST ignore the virtual "d" and "c" 283 rights in MYRIGHTS, ACL and LISTRIGHTS responses. 285 (**) The IMAPEXT Working Group has debated this issue in great length 286 and after reviewing existing ACL implementations concluded that this is 287 a reasonable restriction. 289 3.2. Rights defined in RFC 2086. 291 For convenience, this section lists the rights which were defined in 292 the RFC 2086: 293 "l", "r", "s", "w", "i", "p", "a", "c", "d" and digit rights 294 ("0" .. "9"). 296 The listed rights MUST NOT be returned in the "RIGHTS=" capability 297 string. 299 4. Access control management commands and responses 301 Servers, when processing a command that have an authentication identifier 302 as a parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands), 303 SHOULD first prepare the received identifier using "SASLprep" profile 304 [SASLprep] of the "stringprep" algorithm [StringPrep]. If the 305 preparation of the identifier fails or results in an empty string, the 306 server MUST refuse to perform the command with a BAD response. 308 4.1. SETACL command 310 Arguments: mailbox name 311 authentication identifier 312 access right modification 314 Data: no specific data for this command 316 Result: OK - setacl completed 317 NO - setacl failure: can't set acl 318 BAD - arguments invalid 320 The SETACL command changes the access control list on the 321 specified mailbox so that the specified identifier is granted 322 permissions as specified in the third argument. 324 The third argument is a string containing an optional plus ("+") 325 or minus ("-") prefix, followed by zero or more rights characters. 326 If the string starts with a plus, the following rights are added 327 to any existing rights for the identifier. If the string starts 328 with a minus, the following rights are removed from any existing 329 rights for the identifier. If the string does not start with a 330 plus or minus, the rights replace any existing rights for the 331 identifier. 333 Note that an unrecognized right MUST cause the command to return 334 the BAD response. In particular, server MUST NOT silently ignore 335 unrecognized rights. 337 Example: C: A001 SETACL INBOX.Drafts Chris lrswicda 338 S: A001 OK Setacl complete 340 C: A035 SETACL INBOX.Drafts John lrQswicda 341 S: A035 BAD Uppercase rights are not allowed 343 C: A036 SETACL INBOX.Drafts John lrqswicda 344 S: A036 BAD The q right is not supported 346 4.2. DELETEACL command 348 Arguments: mailbox name 349 authentication identifier 351 Data: no specific data for this command 353 Result: OK - deleteacl completed 354 NO - deleteacl failure: can't delete acl 355 BAD - arguments invalid 357 The DELETEACL command removes any pair for the 358 specified identifier from the access control list for the specified 359 mailbox. 361 Example: C: B001 GETACL INBOX 362 S: * ACL INBOX Fred rwipslxeta -Fred wet $team w 363 S: B001 OK Getacl complete 364 C: B002 DELETEACL INBOX Fred 365 S: B002 OK Deleteacl complete 366 C: B003 GETACL INBOX 367 S: * ACL INBOX -Fred wet $team w 368 S: B003 OK Getacl complete 370 4.3. GETACL command 372 Arguments: mailbox name 374 Data: untagged responses: ACL 376 Result: OK - getacl completed 377 NO - getacl failure: can't get acl 378 BAD - arguments invalid 380 The GETACL command returns the access control list for mailbox in 381 an untagged ACL response. 383 Some implementations may permit multiple forms of an authentication 384 identifier to reference the same IMAP account. Usually, such 385 implementations will have a canonical form that is stored internally. 386 An ACL response caused by an GETACL command may include a 387 canonicalized form of the authentication identifier which might be 388 different from the one used in the corresponding SETACL command. 390 Example: C: A002 GETACL INBOX 391 S: * ACL INBOX Fred rwipsldexta 392 S: A002 OK Getacl complete 394 4.4. LISTRIGHTS command 396 Arguments: mailbox name 397 authentication identifier 399 Data: untagged responses: LISTRIGHTS 401 Result: OK - listrights completed 402 NO - listrights failure: can't get rights list 403 BAD - arguments invalid 405 The LISTRIGHTS command takes a mailbox name and an identifier and 406 returns information about what rights may be granted to the identifier 407 in the ACL for the mailbox. 409 Some implementations may permit multiple forms of an authentication 410 identifier to reference the same IMAP account. Usually, such 411 implementations will have a canonical form that is stored internally. 412 A LISTRIGHTS response caused by a LISTRIGHTS command MUST always 413 return the same form of an authentication identifier as specified 414 by the client. This is to allow the client to correlate the response 415 with the command. 417 Example: C: a001 LISTRIGHTS ~/Mail/saved smith 418 S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte 419 S: a001 OK Listrights completed 421 Example: C: a005 LISTRIGHTS archive.imap anyone 422 S: * LISTRIGHTS archive.imap anyone "" l r s w i p k x t 423 e c d a 0 1 2 3 4 5 6 7 8 9 424 S: a005 Listrights successful 426 4.5. MYRIGHTS command 428 Arguments: mailbox name 430 Data: untagged responses: MYRIGHTS 432 Result: OK - myrights completed 433 NO - myrights failure: can't get rights 434 BAD - arguments invalid 436 The MYRIGHTS command returns the set of rights that the user has 437 to mailbox in an untagged MYRIGHTS reply. 439 Example: C: A003 MYRIGHTS INBOX 440 S: * MYRIGHTS INBOX rwiptsldaex 441 S: A003 OK Myrights complete 443 4.6. ACL response 445 Data: mailbox name 446 zero or more identifier rights pairs 448 The ACL response occurs as a result of a GETACL command. The first 449 string is the mailbox name for which this ACL applies. This is 450 followed by zero or more pairs of strings, each pair contains the 451 identifier for which the entry applies followed by the set of 452 rights that the identifier has. 454 Section 3.1.1 details additional server requirements related to handling 455 of the virtual "d" and "c" rights. 457 4.7. LISTRIGHTS response 459 Data: mailbox name 460 identifier 461 required rights 462 list of optional rights 464 The LISTRIGHTS response occurs as a result of a LISTRIGHTS 465 command. The first two strings are the mailbox name and identifier 466 for which this rights list applies. Following the identifier is a 467 string containing the (possibly empty) set of rights the 468 identifier will always be granted in the mailbox. 470 Following this are zero or more strings each containing a set of 471 rights the identifier may be granted in the mailbox. Rights 472 mentioned in the same string are tied together--either all must be 473 granted to the identifier in the mailbox or none may be granted. 474 Section 3.1.1 details additional server requirements related to handling 475 of the virtual "d" and "c" rights. 477 The same right may not be listed more than once in the LISTRIGHTS 478 command. 480 4.8. MYRIGHTS response 482 Data: mailbox name 483 rights 485 The MYRIGHTS response occurs as a result of a MYRIGHTS command. 486 The first string is the mailbox name for which these rights apply. 487 The second string is the set of rights that the client has. 489 Section 3.1.1 details additional server requirements related to handling 490 of the virtual "d" and "c" rights. 492 5. Rights required to perform different IMAP4rev1 commands 494 Before executing a command an ACL compliant server must check which rights 495 are required to perform it. This section groups command by functions 496 they perform and list the rights required. It also gives the detailed 497 description of any special processing required. 499 For the purpose of this section the UID counterpart of a command is 500 considered to be the same command, e.g. both UID COPY and COPY commands 501 require the same set of rights. 503 The table below summarizes different rights or their combinations that are 504 required in order to perform different IMAP operations. As it is not always 505 possible to express complex right checking and interactions, the description 506 after the table should be used as the primary reference. 508 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 509 | Operations\Rights | l | r | s | w | i | k | x | t | e | a | Any | None | 510 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 511 | LIST | + | | | | | | | | | | | | 512 | SUBSCRIBE | * | | | | | | | | | | | * | 513 | UNSUBSCRIBE | | | | | | | | | | | | + | 514 | LSUB | * | | | | | | | | | | | * | 515 | CREATE (for parent) | | | | | | + | | | | | | | 516 | DELETE | | | | | | | + | ? | ? | | | | 517 | RENAME | | | | | | + | + | | | | | | 518 | COPY/APPEND | | | ? | ? | + | | | ? | | | | | 519 | EXPUNGE/CLOSE | | | | | | | | | + | | | | 520 |SELECT/EXAMINE/STATUS| | + | | | | | | | | | | | 521 | FETCH | | | ? | | | | | | | | | | 522 | STORE flags | | | ? | ? | | | | ? | | | | | 523 | SETACL/DELETEACL | | | | | | | | | | + | | | 524 | GETACL/LISTRIGHTS | | | | | | | | | | + | | | 525 | MYRIGHTS | | | | | | | | | | | + | | 526 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 528 Legend: 529 + - The right is required 530 * - Only one of the rights marked with * is required (see description below) 531 ? - The right is optional (see description below) 532 "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is 533 required 534 "None" - No rights required to perform the command 536 Listing and subscribing/unsubscribing mailboxes: 537 LIST - "l" right is required. 539 Note that if the user has "l" right to a mailbox "A/B", but not to its parent 540 mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist, 541 for example: 542 C: A777 LIST "" * 543 S: * LIST (\NoInferiors) "/" "A/B" 544 S: * LIST () "/" "C" 545 S: * LIST (\NoInferiors) "/" "C/D" 546 S: A777 OK LIST completed 548 SUBSCRIBE - "l" right is required only if the server checks for mailbox existence 549 when performing SUBSCRIBE. 551 UNSUBSCRIBE - no rights required to perform this operation. 553 LSUB - "l" right is required only if the server checks for mailbox existence when 554 performing SUBSCRIBE. 556 Mailbox management: 557 CREATE - "k" right on a nearest existing parent mailbox. When a new 558 mailbox is created it SHOULD inherit the ACL from the parent 559 mailbox (if one exists) in the defined hierarchy. 561 DELETE - "x" right on the mailbox. Note that some servers don't allow 562 to delete a non-empty mailbox. If this is the case, the user 563 would also need "r", "e" and "t" rights, in order to open the 564 mailbox and empty it. 566 The DELETE command MUST delete the ACL associated with the 567 deleted mailbox. 569 RENAME - Moving a mailbox from one parent to another requires the "x" right 570 on the mailbox itself and the "k" right for the new parent. 571 For example, if the user wants to rename mailbox named "A/B/C" to 572 "D/E", the user must have the "x" right for the mailbox "A/B/C" 573 and the "k" right for the mailbox "D". 575 The RENAME command SHOULD NOT change the ACLs on the renamed 576 mailbox and submailboxes. 578 Copying or appending messages: 580 Before performing a COPY/APPEND command the server MUST check if the 581 user has "i" right for the target mailbox. If the user doesn't have "i" 582 right, the operation fails. Otherwise for each copied/appended message 583 the server MUST check if the user has 584 "t" right - when the message has \Deleted flag set 585 "s" right - when the message has \Seen flag set 586 "w" right for all other message flags. 587 Only when the user has a particular right the corresponding flags are 588 stored for the newly created message. The server MUST NOT fail 589 a COPY/APPEND if the user has no rights to set a particular flag. 591 Example: C: A003 MYRIGHTS TargetMailbox 592 S: * MYRIGHTS TargetMailbox rwis 593 S: A003 OK Myrights complete 595 C: A004 FETCH 1:3 (FLAGS) 596 S: * 1 FETCH (FLAGS (\Draft \Deleted) 597 S: * 2 FETCH (FLAGS (\Answered) 598 S: * 3 FETCH (FLAGS ($Forwarded \Seen) 599 S: A004 OK Fetch Completed 601 C: A005 COPY 1:3 TargetMailbox 602 S: A005 OK Copy completed 604 C: A006 SELECT TargetMailbox 605 ... 606 S: A006 Select Completed 608 Let's assume that the copied messages received message numbers 77:79. 610 C: A007 FETCH 77:79 (FLAGS) 611 S: * 77 FETCH (FLAGS (\Draft)) 612 S: * 78 FETCH (FLAGS (\Answered)) 613 S: * 79 FETCH (FLAGS ($Forwarded \Seen)) 614 S: A007 OK Fetch Completed 616 \Deleted flag was lost on COPY, as the user has no "t" right in the 617 target mailbox. 619 If the MYRIGHTS command with the tag A003 would have returned: 620 S: * MYRIGHTS TargetMailbox rsti 622 the response from the FETCH with the tag A007 would have been: 624 C: A007 FETCH 77:79 (FLAGS) 625 S: * 77 FETCH (FLAGS (\Deleted)) 626 S: * 78 FETCH (FLAGS ()) 627 S: * 79 FETCH (FLAGS (\Seen)) 628 S: A007 OK Fetch Completed 630 In the latter case \Answered, $Forwarded and \Draft flags were lost 631 on COPY, as the user has no "w" right in the target mailbox. 633 Expunging the selected mailbox: 634 EXPUNGE - "e" right on the selected mailbox. 636 CLOSE - "e" right on the selected mailbox. If the server is unable to 637 expunge the mailbox because the user doesn't have the "e" right, 638 the server MUST ignore expunge request, close the mailbox 639 and return tagged OK response. 641 Fetch information about a mailbox and its messages: 642 SELECT/EXAMINE/STATUS - "r" right on the mailbox. 644 FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it, 645 if the current user doesn't have "s" right. 647 Changing flags: 648 STORE - the server MUST check if the user has 649 "t" right - when the user modifies \Deleted flag 650 "s" right - when the user modifies \Seen flag 651 "w" right for all other message flags. 652 STORE operation SHOULD NOT fail if the user has rights to modify at least 653 one flag specified in the STORE, as the tagged NO response to a STORE 654 command is not handled very well by deployed clients. 656 Changing ACLs: 657 SETACL/DELETEACL - "a" right on the mailbox. 659 Reading ACLs: 660 GETACL - "a" right on the mailbox. 662 MYRIGHTS - any of the following rights is required to perform 663 the operation: "l", "r", "i", "k", "x", "a". 665 LISTRIGHTS - "a" right on the mailbox. 667 6. Other considerations 669 6.1. Additional requirements and Implementation notes 671 6.1.1. Servers 673 This document defines an additional capability that is used to announce 674 the list of extra rights (excluding the ones defined in the RFC 2086) 675 supported by the server. The set of rights MUST include "t", "e", "x" 676 and "k". Note that the extra rights can appear in any order. 678 Example: C: 1 capability 679 S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ ACL RIGHTS=texk 680 S: 1 OK completed 682 Any server implementing an ACL extension MUST accurately reflect the current 683 user's rights in FLAGS and PERMANENTFLAGS responses. 685 Example: C: A142 SELECT INBOX 686 S: * 172 EXISTS 687 S: * 1 RECENT 688 S: * OK [UNSEEN 12] Message 12 is first unseen 689 S: * OK [UIDVALIDITY 3857529045] UIDs valid 690 S: * OK [UIDNEXT 4392] Predicted next UID 691 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 692 S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited 693 S: A142 OK [READ-WRITE] SELECT completed 694 C: A143 MYRIGHTS INBOX 695 S: * MYRIGHTS INBOX lrwis 696 S: A143 OK completed 698 Note that in order to get better performance the client may pipeline 699 SELECT and MYRIGHTS commands: 701 C: A142 SELECT INBOX 702 C: A143 MYRIGHTS INBOX 703 S: * 172 EXISTS 704 S: * 1 RECENT 705 S: * OK [UNSEEN 12] Message 12 is first unseen 706 S: * OK [UIDVALIDITY 3857529045] UIDs valid 707 S: * OK [UIDNEXT 4392] Predicted next UID 708 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 709 S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited 710 S: A142 OK [READ-WRITE] SELECT completed 711 S: * MYRIGHTS INBOX lrwis 712 S: A143 OK completed 714 Servers MAY cache the rights a user has on a mailbox when the mailbox 715 is selected, so that if a client's rights on a mailbox are changed with 716 SETACL or DELETEACL, commands specific to the selected state (e.g., STORE, 717 EXPUNGE) might not reflect the changed rights until the mailbox is 718 re-selected. If the server checks the rights on each command, then it SHOULD 719 send FLAGS and PERMANENTFLAGS responses if they have changed. 721 An ACL server MAY modify one or more ACL for one or more identifier as a 722 side effect of modifying the ACL specified in a SETACL/DELETEACL. 723 If the server does that it MUST send untagged ACL response to notify the 724 client about the changes made. 726 6.1.2. Clients 728 A client implementation that allows a user to read and update ACLs MUST 729 preserve unrecognized rights that it doesn't allow the user to change 730 when updating the rights. Otherwise the client may unintentionally remove 731 permissions. 733 6.2. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes 735 A particular ACL server implementation may allow "shared multiuser 736 access" to some mailboxes. "Shared multiuser access" to a mailbox means 737 that multiple different users are able to access the same mailbox, 738 if they have proper access rights. "Shared multiuser access" to the 739 mailbox doesn't mean that the ACL for the mailbox is currently set 740 to allow access by multiple users. Let's denote a "shared multiuser 741 write access" as a "shared multiuser access" when a user may be 742 granted flag modification rights (any of "w", "s" or "t"). 744 Section 5 describes which rights are required for modifying different flags. 746 If the ACL server implements some flags as shared for a mailbox (i.e., 747 the ACL for the mailbox may be set up so that changes to those flags are 748 visible to another user), let's call the set of rights associated with these 749 flags (as described in Section 5) for that mailbox collectively as 750 "shared flag rights". Note that "shared flag rights" set MAY be different 751 for different mailboxes. 753 If the server doesn't support "shared multiuser write access" to a 754 mailbox or doesn't implement shared flags on the mailbox, "shared flag 755 rights" for the mailbox is defined to be the empty set. 757 Example 1: Mailbox "banan" allows "shared multiuser write access" and 758 implements flags \Deleted, \Answered and $MDNSent as 759 shared flags. "Shared flag rights" for the mailbox "banan" 760 is a set containing flags "t" (because system flag \Deleted 761 requires "t" right) and "w" (because both \Answered and 762 $MDNSent require "w" right). 764 Example 2: Mailbox "apple" allows "shared multiuser write access" and 765 implements \Seen system flag as shared flag. "Shared flag 766 rights" for the mailbox "apple" contains "s" right, 767 because system flag \Seen requires "s" right. 769 Example 3: Mailbox "pear" allows "shared multiuser write access" and 770 implements flags \Seen, \Draft as shared flags. "Shared flag 771 rights" for the mailbox "apple" is a set containing flags "s" 772 (because system flag \Seen requires "s" right) and "w" 773 (because system flag \Draft requires "w" right). 775 The server MUST include a READ-ONLY response code in the tagged OK response to 776 a SELECT command if none of the following rights is granted to the 777 current user: 778 "i", "e" and "shared flag rights"*. 779 The server SHOULD include a READ-WRITE response code in the tagged OK response 780 if at least one of the "i", "e" or "shared flag rights"* is granted to the 781 current user. 783 * - Note that a future extension to this document may extend the list of 784 rights that causes the server to return the READ-WRITE response code. 786 Example 1 (continued): The user that has "lrs" rights for the mailbox 787 "banan". The server returns READ-ONLY response 788 code on SELECT, as none of "iewt" rights is 789 granted to the user. 791 Example 2 (continued): The user that has "rit" rights for the mailbox 792 "apple". The server returns READ-WRITE response 793 code on SELECT, as the user has "i" right. 795 Example 3 (continued): The user that has "rset" rights for the mailbox 796 "pear". The server returns READ-WRITE response 797 code on SELECT, as the user has "e" and "s" rights. 799 7. Security Considerations 801 An implementation must make sure the ACL commands themselves do not 802 give information about mailboxes with appropriately restricted ACL's. 803 For example, a GETACL command on a mailbox for which the user has 804 insufficient rights should not admit that the mailbox exists, much less 805 return the mailbox's ACL. 807 LISTRIGHTS command MUST NOT check that a particular identifier exists, 808 however it SHOULD recognize special identifiers like "anyone". 810 IMAP clients implementing ACL that are able to modify ACLs SHOULD 811 warn a user that wants to give full access (or even just the "a" right) 812 to the special identifier "anyone". 814 8. Formal Syntax 816 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 817 Non-terminals referenced but not defined below are as defined by 818 [IMAP4]. 820 Except as noted otherwise, all alphabetic characters are 821 case-insensitive. The use of upper or lower case characters to 822 define token strings is for editorial clarity only. Implementations 823 MUST accept these strings in a case-insensitive fashion. 825 LOWER_ALPHA = %x61-7A ;; a-z 827 acl_data = "ACL" SP mailbox *(SP identifier SP 828 rights) 830 deleteacl = "DELETEACL" SP mailbox SP identifier 832 getacl = "GETACL" SP mailbox 834 identifier = astring 836 listrights = "LISTRIGHTS" SP mailbox SP identifier 838 listrights_data = "LISTRIGHTS" SP mailbox SP identifier 839 SP rights *(SP rights) 841 mod_rights = astring 842 ;; +rights to add, -rights to remove 843 ;; rights to replace 845 myrights = "MYRIGHTS" SP mailbox 847 myrights_data = "MYRIGHTS" SP mailbox SP rights 849 new_rights = 1*LOWER_ALPHA 850 ;; MUST include "t", "e", "x" and "k". 851 ;; MUST NOT include standard rights listed 852 ;; in section 3.2 854 rights = astring 855 ;; only lowercase ASCII letters and digits 856 ;; are allowed. 858 rights_capa = "RIGHTS=" new_rights 859 ;; RIGHTS=... capability 861 setacl = "SETACL" SP mailbox SP identifier 862 SP mod_rights 864 9. IANA Considerations 866 IMAP4 capabilities are registered by publishing a standards track or 867 IESG approved experimental RFC. The registry is currently located 868 at: 870 http://www.iana.org/assignments/imap4-capabilities 872 This document defines the RIGHTS= IMAP capability. IANA is requested 873 to add this capability to the registry. 875 10. References 877 10.1. Normative References 879 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 880 Requirement Levels", RFC 2119, Harvard University, March 1997. 882 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 883 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 884 November 1997. 886 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 887 4rev1", RFC 3501, University of Washington, March 2003. 889 [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", 890 RFC 3629, Alis Technologies, November 2003. 892 [Stringprep] Hoffman, P., Blanchet, M., "Preparation of 893 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 895 [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names 896 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 898 10.2. Informative References 900 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie Mellon, 901 January 1997. 903 11. Editor's Address 905 Alexey Melnikov 906 email: alexey.melnikov@isode.com 908 Isode Limited 910 12. IPR Disclosure Acknowledgement 912 By submitting this Internet-Draft, I certify that any applicable 913 patent or other IPR claims of which I am aware have been disclosed, 914 and any of which I become aware will be disclosed, in accordance with 915 RFC 3668. 917 13. Intellectual Property Statement 919 The IETF takes no position regarding the validity or scope of any 920 intellectual property or other rights that might be claimed to 921 pertain to the implementation or use of the technology described in 922 this document or the extent to which any license under such rights 923 might or might not be available; neither does it represent that it 924 has made any effort to identify any such rights. Information on the 925 IETF's procedures with respect to rights in standards-track and 926 standards-related documentation can be found in BCP-11. Copies of 927 claims of rights made available for publication and any assurances of 928 licenses to be made available, or the result of an attempt made to 929 obtain a general license or permission for the use of such 930 proprietary rights by implementors or users of this specification can 931 be obtained from the IETF Secretariat. 933 The IETF invites any interested party to bring to its attention any 934 copyrights, patents or patent applications, or other proprietary 935 rights which may cover technology that may be required to practice 936 this standard. Please address the information to the IETF Executive 937 Director. 939 14. Full Copyright Statement 941 Copyright (C) The Internet Society (2005). This document is subject 942 to the rights, licenses and restrictions contained in BCP 78 and 943 except as set forth therein, the authors retain all their rights. 945 This document and the information contained herein are provided on an 946 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 947 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 948 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 949 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 950 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 951 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 953 Acknowledgement 955 Funding for the RFC Editor function is currently provided by the 956 Internet Society. 958 Appendix A. Changes since RFC 2086 960 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 962 2. Specified that mailbox deletion is controled by the "x" right and 963 EXPUNGE is controlled by the "e" right. 965 3. Added the "t" right that controls STORE \Deleted. Redefined the "d" 966 right to be a macro for "e", "t" and possibly "x". 968 4. Added the "k" right that controls CREATE. Redefined the "c" 969 right to be a macro for "k" and possibly "x". 971 5. Specified that the "a" right also controls DELETEACL. 973 6. Specified that the "r" right also controls STATUS. 975 7. Removed the requirement to check the "r" right for CHECK, SEARCH and 976 FETCH, as this is required for SELECT/EXAMINE to be successful. 978 8. LISTRIGHTS requires the "a" right on the mailbox (same as SETACL). 980 9. Deleted "PARTIAL", this is a deprecated feature of RFC 1730. 982 10. Specified that the "w" right controls setting flags other than \Seen 983 and \Deleted on APPEND. Also specified that the "s" right controls 984 the \Seen flag and that the "t" right controls the \Deleted flag. 986 11. Specified that SUBSCRIBE is NOT allowed with the "r" right. 988 12. Specified that the "l" right controls SUBSCRIBE. 990 13. GETACL is NOT allowed with the "r" right, even though there are 991 several implementations that allows that. If a user only has "r" 992 right, GETACL can disclose information about identifiers existing 993 on the mail system. 995 14. Clarified that RENAME requires the "k" right for the new parent and 996 the "x" right for the old name. 998 15. Added new section that describes which rights are required and/or 999 checked when performing various IMAP commands. 1001 16. Added mail client security considerations when dealing with special 1002 identifier "anyone". 1004 17. Clarified that negative rights are not the same as DELETEACL. 1006 18. Added "Compatibility with RFC 2086" section. 1008 19. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY 1009 response codes. 1011 20. Changed BNF to ABNF. 1013 21. Added "Implementation Notes" section. 1015 22. Updated "References" section. 1017 23. Added more examples. 1019 24. Clarified when the virtual "c" and "d" rights are returned in ACL, 1020 MYRIGHTS and LISTRIGHTS responses. 1022 Appendix B. Compatibility with RFC 2086 1024 This section gives guidelines how an existing RFC 2086 server 1025 implementation may be updated to comply with this document. 1027 This document splits the "d" right into several new different rights: 1028 "t", "e" and possibly "x" (see section 3.1.1 for more details). The "d" 1029 right remains for backwards-compatibility but it is a virtual right. 1030 The server should implement one of the following two approaches to 1031 handle the "d" right and the new rights that have replaced it. 1033 a). "t", "e" (and possibly "x) together - almost no changes. 1034 b). Implement separate "x", "t" and "e". Return the "d" right in a 1035 MYRIGHTS response or an ACL response containing ACL 1036 information when any of the "t", "e" (and "x") is granted. 1038 In a similar manner this document splits the "c" right into several 1039 new different rights: "k" and possibly "x" (see section 3.1.1 for more 1040 details). The "c" right remains for backwards-compatibility but it is 1041 a virtual right. The server should implement one of the two approaches 1042 described above. 1044 Also check Sections 6.1 and 6.2, as well as the appendix A to see 1045 other changes required. Server implementors should check which rights 1046 are required to invoke different IMAP4 commands as described in 1047 Section 5. 1049 Appendix C. Known deficiencies 1051 This specification has some known deficiencies including: 1053 1. This is inadequate to provide complete read-write access to 1054 mailboxes protected by Unix-style rights bits because there is no 1055 equivalent to "chown" and "chgrp" commands nor is there a good way 1056 to discover such limitations are present. 1058 2. Because this extension leaves the specific semantics of how rights 1059 are combined by the server as implementation defined, the ability 1060 to build a user-friendly interface is limited. 1062 The work-in-progress "ACL2" extension is intended to redesign this 1063 extension to address these deficiencies without the constraint of 1064 backwards-compatibility and may eventually supercede this facility. 1065 However, RFC 2086 is deployed in multiple implementations so this 1066 intermediate step which fixes the straightforward deficiencies in a 1067 backwards compatible fashion is considered worthwhile. 1069 Appendix D. Acknowledgment 1071 This document is a revision of the RFC 2086 written by John G. Myers. 1073 Editor appreciates comments received from Mark Crispin, Chris Newman, 1074 Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole, 1075 Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie 1076 Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon 1077 Nerenberg and other participants of the IMAPEXT working group.