idnits 2.17.1 draft-ietf-imapext-acl-06.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 1057 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 147 instances of too long lines in the document, the longest one being 20 characters in excess of 72. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 2002) is 7854 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'UNSEEN 12' is mentioned on line 842, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 843, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 844, but not defined == Unused Reference: 'UTF-8' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'QUOTA' is defined on line 870, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2087 (ref. 'QUOTA') (Obsoleted by RFC 9208) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 3 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-acl-06.txt October 2002 5 IMAP4 ACL extension 7 Status of this Memo 9 This document is an Internet Draft and is in full conformance with 10 all provisions of Section 10 of RFC 2026. 12 Internet Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its Areas, and its Working Groups. Note that 14 other groups may also distribute working documents as Internet 15 Drafts. Internet Drafts are draft documents valid for a maximum of 16 six months. Internet Drafts may be updated, replaced, or obsoleted 17 by other documents at any time. It is not appropriate to use 18 Internet Drafts as reference material or to cite them other than as 19 ``work in progress''. 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 28 munnari.oz.au. 30 A revised version of this draft document will be submitted to the RFC 31 editor as a Proposed Standard for the Internet Community. Discussion 32 and suggestions for improvement are requested. Distribution of this 33 draft is unlimited. 35 0. Open issues 37 This section will be removed when the draft will be published as RFC. 38 It is intended to simplify discussion. 40 1). Require support for special identifier "disabled" for 41 "ACL2=MOST-SPECIFIC" model? 43 2). Obsolete LISTRIGHTS? 45 Mark Crispin wrote: 47 > [...] If rights are tied in an 48 > implementation, the implementation must be conservative in granting 49 > rights in response to SETACL commands--unless all rights in a tied 50 > set are specified, none of that set should be included in the ACL 51 > entry for that identifier. A client may discover the set of rights 52 > which may be granted to a given identifier in the ACL for a given 53 > mailbox by using the LISTRIGHTS command. 54 > 55 > This was in RFC 2086 as well. 56 > 57 > Do we really want these semantics? 58 > 59 > The effect of this is that it is mandatory to do a LISTRIGHTS prior to any 60 > SETACL (and multiple LISTRIGHTS prior to any REPLACEACL), since otherwise 61 > there is no way for a client to know how to grant a particular right to an 62 > identifier. 63 > 64 > Presumably, the reason for these semantics is so a client can review the 65 > impact of granting a particular right if it's tied to another. But will 66 > any client actually do this? Or will clients just blindly do the 67 > LISTRIGHTS to get the necessary incantation for SETACL? 68 > 69 > What I see is no savings of work for a client which cares about any side 70 > effects due to tied-rights, but a lot of extra work for clients which do 71 > not care. 73 Alexey Melnikov replied: 75 I tend to agree. I would rather have a new response code LISTRIGHTS that is 76 returned in NO response to SETACL command. 77 Imagine that the client wants to grant "cp" rights to a user "smith". The 78 client instead of doing: 80 C: A001 LISTRIGHTS ~/Mail/saved smith 81 S: * LISTRIGHTS ~/Mail/saved smith la r swi cdext 82 S: A001 OK Listrights completed 83 C: A002 SETACL ~/Mail/saved smith cdextp 84 S: A002 OK Setacl complete 86 will do the following (this assumes that the server doesn't want to grant a 87 right unless all tied rights are specified by the client): 89 C: A001 SETACL ~/Mail/saved smith cp 90 S: A001 NO [LISTRIGHTS la r swi cdext] No some rights are tied, 91 specify both 92 C: A002 SETACL ~/Mail/saved smith cdextp 93 S: A002 OK Setacl complete 94 C: A002 LISTRIGHTS ~/Mail/saved smith 96 and if the server sets all tied rights automatically if at least one of them 97 is specified (not recommended by the document but still possible): 99 C: A001 SETACL ~/Mail/saved smith cp 100 S: * ACL ~/Mail/saved smith cdextp 101 S: A001 OK Setacl complete 103 3). Other editorial comments/questions are enclosed in << and >>. 105 1. Abstract 107 The ACL extension of the Internet Message Access Protocol [IMAP4] 108 permits access control lists to be manipulated through the IMAP 109 protocol. 111 2. Conventions Used in this Document 113 In examples, "C:" and "S:" indicate lines sent by the client and 114 server respectively. 116 In all examples "/" character is used as hierarchy separator. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 122 3. Introduction and Overview 124 The ACL extension is present in any IMAP4 implementation which 125 returns a capability starting with "ACL2=" as one of the supported 126 capabilities to the CAPABILITY command. 128 An access control list is a set of pairs. 130 Identifier is a UTF-8 string. An identifier may have one of the following 131 forms: 132 a). "anyone" - special identifier that refers to the universal identity 133 (all authentications, including anonymous). 134 b). "authuser" - special identifier that refer to all authenticated users, 135 but not anonymous. 136 c). "owner" - special identifier that refers to the owner of a mailbox 137 (if any). 138 d). "administrators" - special identifier that refers to all users with 139 administrative rights. 140 e). "user=" - refers to a user. Here "" is a user name string 141 accepted by the LOGIN or AUTHENTICATE commands. 142 f). "group=" - refers to a group. 143 g). "-", where is one of a).-f). This is 144 reserved for "negative rights", described below. 146 <> 148 Note that a server is not required to implement any special identifier mentioned 149 above. However if it allows a user to perform ACL operations on any one of them, 150 server MUST use the semantic as described above. 152 All other identifier names are reserved for future definition in an 153 extension or revision to this specification (also known as ACL2). 155 Rights is a string listing a (possibly empty) set of alphanumeric 156 characters, each character listing a set of operations which is being 157 controlled. Letters are reserved for ''standard'' rights, listed 158 below. The set of standard rights may only be extended by a 159 standards-track document. Digits are reserved for implementation or 160 site defined rights. The currently defined standard rights are: 162 l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox) 163 r - read (SELECT the mailbox, perform STATUS, CHECK, FETCH, SEARCH, 164 COPY from mailbox) 165 s - keep seen/unseen information across sessions (set or clear \SEEN flag 166 via STORE, APPEND or COPY) 167 w - write (set or clear flags other than \SEEN and \DELETED via STORE, 168 APPEND or COPY) 169 i - insert (perform APPEND, COPY into mailbox) 170 p - post (send mail to submission address for mailbox, 171 not enforced by IMAP4 itself) 172 c - create mailboxes (CREATE new sub-mailboxes in any 173 implementation-defined hierarchy, parent mailbox for the new 174 mailbox name in RENAME). 175 When a new mailbox is created it SHOULD inherit rights from 176 the parent mailbox (if one exists) in the defined hierarchy. 177 x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) 178 t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag 179 during APPEND/COPY) 180 e - perform EXPUNGE and expunge as a part of CLOSE 181 d - This right is defined for backward compatibility with ACL 182 extension (RFC 2086). If a client sets "d" right, the server MUST 183 set "x", "e" and "t" rights. When the client clears the "d" right, 184 the server MUST clear "x", "e" and "t" rights. When all three of "x", 185 "e" and "t" are set, the server MUST return "d" right in response to 186 a ACL GET command. If "x", "e" and "t" rights are not tied together, 187 "d" right MUST NOT be returned in a ACL LIST response. 188 a - administer (perform ACL STORE, ACL SET and ACL DELETE) 190 An implementation may tie rights together or may force rights to 191 always or never be granted to particular identifiers. For example, 192 in an implementation that uses unix mode bits, the rights "wisd" are 193 tied, the "a" right is always granted to the owner of a mailbox and 194 is never granted to another user. If rights are tied in an 195 implementation, the implementation must be conservative in granting 196 rights in response to ACL STORE commands--unless all rights in a tied 197 set are specified, none of that set should be included in the ACL 198 entry for that identifier. A client may discover the set of rights 199 which may be granted to a given identifier in the ACL for a given 200 mailbox by using the ACL LIST command. 202 When an identifier in an ACL starts with a dash ("-"), that indicates 203 that associated rights are to be removed from the identifier that is 204 prefixed by the dash. This is referred to as a "negative right". 205 This differs from ACL DELETE in that a negative right is added to the 206 ACL, and is part of the calculation of the rights. 208 For example, if the identifier "-user=fred" is granted the "w" right, 209 that indicates that the "w" right is to be removed from users matching 210 the identifier "user=fred", even though the user "fred" might have 211 the "w" right as a consequence of some other identifier in the ACL. 212 A ACL DELETE of "user=fred" simply deletes the identifier "user=fred" 213 from the ACL; it does not affect any rights that the user "fred" 214 may get from another ACL. 216 Server implementations are not required to support "negative right" 217 identifiers. 219 It is possible for multiple identifiers in an access control list to 220 apply to a given user (or other authentication identity). For 221 example, an ACL may include rights to be granted to the identifier 222 matching the user, one or more implementation-defined identifiers 223 matching groups which include the user, and/or the identifier 224 "anyone". How these rights are combined to determine the user's 225 access is implementation-defined. The set of rules that describes 226 how access is calculated is defined by a rule identifier (rule-ID). 228 A client may determine the set of rights granted to the logged-in user 229 for a given mailbox by using the MYRIGHTS command. 231 If a server implementing ACL2 uses the union of the rights granted to 232 the applicable identifiers minus the union of the negative rights 233 in order to calculate access, it MUST report "ACL2=UNION" in the server's 234 capability list. 236 An implementation may instead choose to only use those rights granted 237 to the most specific identifier present in the ACL. In this case the 238 server MUST report "ACL2=MOST-SPECIFIC" in the server's capability 239 list. 241 If the server implements any other policy for rights calculation, 242 it MUST be either registered with IANA using the template provided in 7.1 243 or start with "X-". The server MUST report one and only one "ACL2=" 244 capability in its CAPABILITY response. 246 3.1. Rights required to perform different IMAP4rev1 commands 248 Before executing a command an ACL2 compliant server must check which rights 249 are required to perform it. This section groups command by functions 250 they perform and list the rights required. It also gives the detailed description 251 of any special processing required. 253 Listing and subscribing/unsubscribing mailboxes: 254 LIST - "l" right is required. 256 Note, that if the user has "l" right to a mailbox "A/B", but not to its parent 257 mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist, 258 for example: 259 C: A777 LIST "" * 260 S: * LIST (\NoInferiors) "/" "A/B" 261 S: * LIST () "/" "C" 262 S: * LIST (\NoInferiors) "/" "C/D" 263 S: A777 OK LIST completed 265 SUBSCRIBE - "l" right is required only if the server checks for mailbox existence 266 when performing SUBSCRIBE. 268 <> 270 UNSUBSCRIBE - no rights required to perform this operation. 272 LSUB - "l" right is required only if the server checks for mailbox existence when 273 performing SUBSCRIBE. 275 Mailbox management: 276 CREATE - "c" right on a nearest existing parent mailbox. When a new mailbox 277 is created it SHOULD inherit rights from the parent mailbox (if one exists) 278 in the defined hierarchy. 280 DELETE - "x" right on the mailbox. 282 RENAME - Moving a mailbox from one parent to another 283 requires "x" right on the mailbox itself and "c" right for the new parent. 284 For example, if the user wants to rename mailbox named "A/B/C" 285 to "D/E", the user must have "x" right 286 for the mailbox "A/B/C" and "c" right for the mailbox "D". 288 Copying or appending messages: 290 Before performing a COPY/APPEND command the server MUST check if the user has "i" right 291 for the target mailbox. If the user doesn't have "i" right, the operation fails. 292 Otherwise for each copied/appended message the server MUST check if the user has 293 "t" right - when the message has \Deleted flag set 294 "s" right - when the message has \Seen flag set 295 "w" right for all other message flags. 296 Only when the user has a particular right the corresponding flags are stored for the 297 newly created message. The server MUST NOT fail a COPY/APPEND if the user has no rights 298 to set a particular flag. 300 <> 302 Expunging the selected mailbox: 303 EXPUNGE - "e" right on the selected mailbox. 305 CLOSE - "e" right on the selected mailbox. Server MUST NOT fail CLOSE operation if it is 306 unable to expunge the mailbox. 308 Fetch information about a mailbox and its messages: 309 SELECT/EXAMINE/STATUS - "r" right on the mailbox. 311 FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it, if the 312 current user doesn't have "s" right. 314 Changing flags: 315 STORE - the server MUST check if the user has 316 "t" right - when the user modifies \Deleted flag 317 "s" right - when the user modifies \Seen flag 318 "w" right for all other message flags. 319 STORE operation SHOULD NOT fail if the user has rights to modify at least one flag 320 specified in the STORE. 322 Changing ACLs: 323 ACL STORE/DELETE/SET - "a" right on the mailbox (*). 325 Reading ACLs: 326 ACL GET - "a" right on the mailbox (*). 327 <> 330 MYRIGHTS - any of the following rights is required to perform the operation: 331 "l", "r", "i", "c", "x", "e", "a". 333 ACL LIST - same as for MYRIGHTS(*). 335 (*) Note, that when one or more mailbox pattern is specified, 336 'l' right is required for each mailbox matching the mailbox pattern(s). 338 4. Commands 340 All ACL commands (i.e. ACL STORE/DELETE/SET/GET/LIST, except for MYRIGHTS) 341 accept either a single mailbox name or several mailbox patterns as a 342 parameter. Mailbox pattern is a mailbox with wildcards, wildcards are 343 interpreted as described in [IMAP4] LIST command. In order to distinguish 344 between a mailbox name (that is allowed to have wildcard characters '*' 345 and '%') and a mailbox pattern, the latter is always represented as a 346 parenthesized list. 348 For simplicity the bahaviour of ACL STORE/DELETE/SET/GET/LIST commands 349 is described for a single mailbox case. When one or more mailbox pattern 350 is specified, the server internally performs LIST command for all specified 351 patterns and than it combines the results. Note, that only mailboxes for 352 which the user has 'l' right are included in the combined result. If the 353 combined result has no mailboxes, an ACL operation completes with success 354 and the tagged OK response is sent. Otherwise the requested operation is 355 performed for each mailbox in the combined result. If a particular mailbox 356 causes the operation to fail (e.g. insufficient permissions), instead of 357 failing the whole command, an untagged ACLFAILED response is sent for this 358 mailbox and the operation continues for the rest of the mailboxes. 359 If the server knows that the operation will fail in the same 360 manner for all matching mailboxes (e.g. user doesn't exist), it SHOULD 361 return tagged NO response instead of sending several untagged ACLFAILED 362 responses. 364 Example: C: A002 ACL SET (INBOX Personal/*) user=Fred rwist 365 S: * ACLFAILED Personal/ABC 366 S: A002 OK acl set complete 368 <> 370 Example: C: A002 ACL SET (Fruits/Apples/*) user=Zak lrs 371 S: A002 NO User Zak doesn't exist 373 4.1. ACL STORE 375 Arguments: mailbox name or one or more mailbox masks 376 authentication identifier 377 access right modification 379 Data: OPTIONAL untagged responses: ACLINFO 381 Result: OK - ACL STORE completed 382 NO - ACL STORE failure: can't set acl 383 BAD - command unknown or arguments invalid 385 The ACL STORE command changes the access control list on the 386 specified mailbox so that the specified identifier is granted 387 permissions as specified in the third argument. 389 The third argument is a string containing an optional plus ("+") 390 or minus ("-") prefix, followed by zero or more rights characters. 391 If the string starts with a plus, the following rights are added 392 to any existing rights for the identifier. If the string starts 393 with a minus, the following rights are removed from any existing 394 rights for the identifier. If the string does not start with a 395 plus or minus, the rights replace any existing rights for the 396 identifier. 398 Note, that for "ACL2=UNION" access calculation rule 399 MUST be treated as 400 . Also note that these two commands 401 don't have the same result for "ACL2=MOST-SPECIFIC". 403 An ACL2 server MAY modify one or more ACL for one or more identifier 404 as a side effect of modifying the ACL specified in ACL STORE. If the 405 server does that it MUST send untagged ACLINFO response to notify the 406 client about the changes made. 408 4.2. ACL DELETE 410 Arguments: mailbox name or one or more mailbox masks 411 authentication identifier 413 Data: OPTIONAL untagged responses: ACLINFO 415 Result: OK - ACL DELETE completed 416 NO - ACL DELETE failure: can't delete acl 417 BAD - command unknown or arguments invalid 419 The ACL DELETE command removes any pair for the 420 specified identifier from the access control list for the 421 specified mailbox. 423 An ACL2 server MAY modify one or more ACL for one or more identifier 424 as a side effect of modifying the ACL specified in ACL DELETE. If the 425 server does that it MUST send untagged ACLINFO response to notify the 426 client about the changes made. 428 4.3. ACL SET 430 Arguments: mailbox name or one or more mailbox masks 431 list of (authentication identifier, access rights) pairs 433 Data: OPTIONAL untagged responses: ACLINFO 435 Result: OK - replaceacl completed 436 NO - replaceacl failure: can't replace acl 437 BAD - command unknown or arguments invalid 439 The ACL SET command replaces the access control list of the 440 specified mailbox with the one provided as the second parameter to 441 ACL SET. This command is semantically equivalent to the following 442 sequence of commands: 444 1). ACL GET 445 2). For each (authentication identifier AID, access rights RD) pair returned 446 in the untagged ACL response that was caused by ACL GET, perform 447 ACL DELETE AID 448 3). For each (authentication identifier AIA, access rights RA) pair from 449 the second parameter of ACL SET perform 450 ACL STORE AIA RA 452 An ACL2 server MAY modify one or more ACL for one or more identifier 453 as a side effect of modifying the ACL specified in ACL SET. If the 454 server does that it MUST send untagged ACLINFO response to notify the 455 client about the changes made. 457 4.4. ACL GET 459 Arguments: mailbox name or one or more mailbox masks 461 Data: REQUIRED untagged responses: ACLINFO 463 Result: OK - ACL GET completed 464 NO - ACL GET failure: can't get acl 465 BAD - command unknown or arguments invalid 467 The ACL GET command returns the access control list for mailbox in 468 an untagged ACLINFO reply. 470 Example: C: A002 ACL GET INBOX 471 S: * ACLINFO INBOX user=Fred rwipslextda 472 S: A002 OK acl get complete 474 4.5. ACL LIST 476 Arguments: mailbox name or one or more mailbox masks 477 authentication identifier 479 Data: untagged responses: RIGHTS-INFO 481 Result: OK - ACL LIST completed 482 NO - ACL LIST failure: can't get rights list 483 BAD - command unknown or arguments invalid 485 The ACL LIST command takes a mailbox name and an identifier and 486 returns information about what rights may be granted to the 487 identifier in the ACL for the mailbox. 489 Example: C: a001 ACL LIST ~/Mail/saved user=smith 490 S: * RIGHTS-INFO ~/Mail/saved user=smith la r swi cdext 491 S: a001 OK ACL LIST completed 493 C: a005 ACL LIST archive.imap anyone 494 S: * RIGHTS-INFO archive.imap anyone "" l r s w i p c dtex a 495 0 1 2 3 4 5 6 7 8 9 496 S: a005 OK ACL LIST completed 498 4.6. MYRIGHTS 500 Arguments: mailbox name 502 Data: untagged responses: MYRIGHTS 504 Result: OK - myrights completed 505 NO - myrights failure: can't get rights 506 BAD - command unknown or arguments invalid 508 The MYRIGHTS command returns the set of rights that the user has 509 to mailbox in an untagged MYRIGHTS reply. 511 < as well.>> 526 The user must have any of the following rights to perform this operation: 527 "l", "r", "i", "c", "x", "e", "a". 528 If the user doesn't have any right from the above list, the server 529 MUST behave as if the mailbox doesn't exist. 531 Example: C: A003 MYRIGHTS INBOX 532 S: * MYRIGHTS INBOX rwipsldexta 533 S: A003 OK Myrights complete 535 5. Responses 537 5.1. ACLINFO 539 Data: mailbox name 540 zero or more identifier rights pairs 542 The ACLINFO response occurs as a result of a ACL GET command. It MAY 543 also occur as a result of ACL STORE/DELETE/SET. The first string 544 is the mailbox name for which this ACL applies. This is followed 545 by zero or more pairs of strings, each pair contains the identifier 546 for which the entry applies followed by the set of rights that the 547 identifier has. 549 << There is a proposal to use LISTEXT syntax instead. This requires 550 publishing a new revision of LISTEXT, that in its current form, is not 551 flexible enough. >> 553 5.2. RIGHTS-INFO 555 Data: mailbox name 556 identifier 557 required rights 558 list of optional rights 560 The RIGHTS-INFO response occurs as a result of a ACL LIST 561 command. The first two strings are the mailbox name and 562 identifier for which this rights list applies. Following the 563 identifier is a string containing the (possibly empty) set of 564 rights the identifier will always be granted in the mailbox. 565 Following this are zero or more strings each containing a set of 566 rights the identifier may be granted in the mailbox. Rights 567 mentioned in the same string are tied together--either all must be 568 granted to the identifier in the mailbox or none may be granted. 570 The same right may not be listed more than once in the RIGHTS-INFO 571 response. 573 5.3. ACLFAILED untagged response 575 Contents: OPTIONAL response code (failure reason) 576 mailbox name 578 The ACLFAILED response containing a mailbox name indicates that 579 the ACL operations failed for the specified mailbox. The 580 reason for failure may be described by the response code 581 (if included). 583 Example: C: A002 ACL SET (INBOX Personal/*) user=Fred rwist 584 S: * ACLFAILED Personal/ABC 585 S: A002 OK acl set complete 587 <> 589 <> 591 5.4. MYRIGHTS untagged response 593 Data: mailbox name 594 rights 596 The MYRIGHTS response occurs as a result of a MYRIGHTS command. 597 The first string is the mailbox name for which these rights apply. 598 The second string is the set of rights that the client has. 600 5.5. MYRIGHTS response code 602 Data: rights 604 The MYRIGHTS response code is sent in an untagged OK response 605 that results from SELECT/EXAMINE. Also this response code can be 606 sent at any time after opening a mailbox when the server detects 607 that the set of rights allowed for the logged in user has changed. 609 The MYRIGHT response code is equivalent to MYRIGHTS untagged response 610 for the selected mailbox. 612 6. Formal Syntax 614 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 615 Non-terminals referenced but not defined below are as defined by 616 [IMAP4]. 618 Except as noted otherwise, all alphabetic characters are 619 case-insensitive. The use of upper or lower case characters to 620 define token strings is for editorial clarity only. Implementations 621 MUST accept these strings in a case-insensitive fashion. 623 acl2_command = myrights | "ACL" SPACE acl2_subcommand 625 acl2_subcommand = replaceacl | deleteacl | updateacl | getacl | listrights 627 acl_data = "ACLINFO" SPACE mailbox *(SPACE identifier SPACE rights) 629 always_granted = rights 631 deleteacl = "DELETE" SPACE mbox_or_pat SPACE identifier 633 getacl = "GET" SPACE mbox_or_pat 635 identifier = astring 636 ;; UTF-8 638 << Specify more detailed syntax for identifiers? >> 640 listrights = "LIST" SPACE mbox_or_pat SPACE identifier 642 listrights_data = "RIGHTS-INFO" SPACE mailbox SPACE identifier 643 SPACE always_granted *(SPACE rights) 645 mod_rights = quoted 646 ;; +rights to add, -rights to remove 648 myrights = "MYRIGHTS" SPACE mailbox 650 myrights_data = "MYRIGHTS" SPACE mailbox SPACE rights 652 myrights_rspcod = "MYRIGHTS" SPACE rights 654 replaceacl = "SET" SPACE mbox_or_pat *(SPACE identifier SPACE rights) 656 resp-text-code =/ myrights_data 658 rights = quoted 659 ;; MUST NOT contain leading "+" or "-" 661 updateacl = "STORE" SPACE mbox_or_pat SPACE identifier SPACE mod_rights 663 mbox_or_pat = mailbox / patterns 665 patterns = "(" list-mailbox *(list-mailbox) ")" 667 partialfail_rsp = "ACLFAILED" [SPACE "[" resp-text-code "]" ] SPACE mailbox 668 ;; May contain optional failure reason 670 7. IANA considerations 672 7.1. ACL access calculation rule Registration Template 674 When an access calculation rule for ACL2 extension is registered, the 675 following information is supplied: 677 Rule Identification: specify a string that identifies this 678 rule. Unless the rule is registered with the IANA, the 679 rule's identification must start with "X-". 680 The server supporting a particular rule MUST report 681 "ACL2=" in the capability list. 683 Rule Semantics: specify how access rights for a mailbox are calculated. 685 Negative rights allowed: specify whether "negative right" identifiers are 686 allowed. 688 Groups allowed: specify whether group identifiers are allowed. 690 Special Identifiers: describe whether any implementation defined 691 aliases are allowed and define their meaning. 693 Contact Information: specify the postal and electronic contact 694 information for the author of the feature. 696 8. Initial Registrations 698 8.1. Registration: UNION access calculation rule 700 Rule Identification: UNION 702 Rule Semantics: the union of the rights granted to 703 the applicable identifiers minus the union of the negative rights. 705 Negative rights allowed: Yes. 707 Groups allowed: Yes, but not required. 709 Special Identifiers: No. 711 Contact Information: c.f., the "Editor's Address" section of this 712 memo 714 8.2. Registration: MOST-SPECIFIC access calculation rule 716 Rule Identification: MOST-SPECIFIC 718 Rule Semantics: the rights granted to the most specific identifier 719 present in the ACL are used, i.e. if the user identifier is present, 720 its ACL is used. If no user identifier is present, but a group that 721 includes this user as a member is present, the group ACL is used. 722 If neither user, nor group identifier is present, but an ACL for 723 a special group "anyone" is present, the ACL for "anyone" is used. 725 Negative rights allowed: No. 727 Groups allowed: Yes, but not required. 729 Special Identifiers: No. 731 Contact Information: c.f., the "Editor's Address" section of this 732 memo 734 9. Security Considerations 736 An implementation must make sure the ACL commands themselves do not 737 give information about mailboxes with appropriately restricted ACL's. 738 For example, a ACL GET command on a mailbox for which the user has 739 insufficient rights should not admit the mailbox exists, much less 740 return the mailbox's ACL. 742 IMAP clients implementing ACL2 that are able to modify ACLs SHOULD 743 warn a user that wants to give full access to the special identifier 744 "anyone". 746 10. Other considerations 748 10.1. Compatibility with RFC 2086 750 << This has to be written >> 752 10.2. ACL2 interaction with QUOTA extension 754 Server that implement both ACL2 and QUOTA extensions MUST use the following 755 table to determine if a quote operation should be allowed for the user: 757 GETQUOTAROOT - "r" right 758 << Replace with/add "a" and "i"? >> 760 GETQUOTA - no rights required 762 SETQUOTA - implementation defined, as SETQUOTA operates on a quotaroot, 763 not on a mailbox. 765 10.3. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes. 767 A particular ACL2 server implementation may allow "shared multiuser 768 access" to some mailboxes. "Shared multiuser access" to a mailbox means 769 that multiple different users are able to access the same mailbox, 770 if they have proper access rights. "Shared multiuser access" to the 771 mailbox doesn't mean that the ACL for the mailbox is currently set 772 to allow access by multiple users. Let's denote a "shared multiuser 773 write access" as a "shared multiuser access" when a user may be 774 granted flag modification rights (any of "w", "s" or "t"). 776 Section 3.1 ("Rights required to perform different IMAP4rev1 commands") 777 describes which rights are required for modifying different flags. 779 If the ACL2 server implements some flags as shared for a mailbox (i.e., 780 the ACL for the mailbox may be set up so that changes to those flags are 781 visible to another user), let's call the set of rights associated with these 782 flags (as described in 3.1) for that mailbox collectively as "shared flag 783 rights". Note, that "shared flag rights" set MAY be different for different 784 mailboxes. 786 If the server doesn't support "shared multiuser write access" to a 787 mailbox or doesn't implement shared flags on the mailbox, "shared flag 788 rights" for the mailbox is defined to be the empty set. 790 Example 1: Mailbox "banan" allows "shared multiuser write access" and 791 implements flags \Deleted, \Answered and $MDNSent as 792 shared flags. "Shared flag rights" for the mailbox "banan" 793 is a set containing flags "t" (because system flag \Deleted 794 requires "t" right) and "w" (because both \Answered and 795 $MDNSent require "w" right). 797 Example 2: Mailbox "apple" allows "shared multiuser write access" and 798 implements \Seen system flag as shared flag. "Shared flag 799 rights" for the mailbox "apple" contains "s" right, 800 because system flag \Seen requires "s" right. 802 Example 3: Mailbox "pear" allows "shared multiuser write access" and 803 implements flags \Seen, \Draft as shared flags. "Shared flag 804 rights" for the mailbox "apple" is a set containing flags "s" 805 (because system flag \Seen requires "s" right) and "w" 806 (because system flag \Draft requires "w" right). 808 <> 811 The server MUST include a READ-ONLY prefix in the tagged OK response to 812 a SELECT command if none of the following rights is granted to the 813 current user: 814 "i", "e" and "shared flag rights". 815 The server SHOULD include a READ-WRITE prefix in the tagged OK response 816 if at least one of the "i", "e" or "shared flag rights" is granted to the 817 current user. 819 Example 1 (continue): The user that has "lrs" rights for the mailbox 820 "banan". The server returns READ-ONLY response 821 code on SELECT, as none of "iewt" rights is 822 granted to the user. 824 Example 2 (continue): The user that has "rit" rights for the mailbox 825 "apple". The server returns READ-WRITE response 826 code on SELECT, as the user has "i" right. 828 Example 3 (continue): The user that has "rset" rights for the mailbox 829 "pear". The server returns READ-WRITE response 830 code on SELECT, as the user has "e" and "s" rights. 832 10.4. Additional requirements and Implementation notes 834 Any server implementing an ACL2 extension MUST accurately reflect the current 835 user's rights in FLAGS and PERMANENTFLAGS responses. The server SHOULD issue 836 a MYRIGHTS response code in an untagged OK response as a result of a SELECT 837 or EXAMINE command. 839 Example: C: A142 SELECT INBOX 840 S: * 172 EXISTS 841 S: * 1 RECENT 842 S: * OK [UNSEEN 12] Message 12 is first unseen 843 S: * OK [UIDVALIDITY 3857529045] UIDs valid 844 S: * OK [UIDNEXT 4392] Predicted next UID 845 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 846 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 847 S: * OK [MYRIGHTS rwiste] Allowed rights 848 S: A142 OK [READ-WRITE] SELECT completed 850 An ACL2 server MAY modify one or more ACL for one or more identifier as a 851 side effect of modifying the ACL specified in ACL STORE/DELETE/SET. 852 If the server does that it MUST send untagged ACL response to notify the 853 client about the changes made. 855 11. References 857 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 858 Requirement Levels", RFC 2119, Harvard University, March 1997. 860 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 861 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 862 November 1997. 864 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 865 4rev1", RFC 2060, University of Washington, December 1996. 867 [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", 868 RFC 2279, Alis Technologies, January 1998. 870 [QUOTA] Myers, J., "IMAP4 QUOTA extension", RFC 2087, Carnegie Mellon 871 University, January 1997. 873 12. Aknowledgement 875 This document is a revision of the RFC 2086 written by John G. Myers. 877 Editor appreciates comments received from Mark Crispin, Chris Newman, 878 Cyrus Daboo, John G. Myers, Curtis King, Lyndon Nerenberg, Larry Greenfield, 879 Vladimir Butenko, Dave Cridland and other members of IMAPEXT working group. 881 13. Editor's Address 883 Alexey Melnikov 884 mailto: mel@messagingdirect.com 886 ACI WorldWide/MessagingDirect 887 59 Clarendon Road, Watford, 888 Hertfordshire, United Kingdom, WD17 1FQ 890 Phone: +44 1923 81 2877 892 14. Full Copyright Statement 894 Copyright (C) The Internet Society 2002. All Rights Reserved. 896 This document and translations of it may be copied and furnished to 897 others, and derivative works that comment on or otherwise explain it 898 or assist in its implementation may be prepared, copied, published 899 and distributed, in whole or in part, without restriction of any 900 kind, provided that the above copyright notice and this paragraph 901 are included on all such copies and derivative works. However, this 902 document itself may not be modified in any way, such as by removing 903 the copyright notice or references to the Internet Society or other 904 Internet organizations, except as needed for the purpose of 905 developing Internet standards in which case the procedures for 906 copyrights defined in the Internet Standards process must be 907 followed, or as required to translate it into languages other than 908 English. 910 The limited permissions granted above are perpetual and will not be 911 revoked by the Internet Society or its successors or assigns. 913 This document and the information contained herein is provided on an 914 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 915 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 916 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 917 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 918 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 920 Appendix A. Changes since RFC 2086 922 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 924 2. Changed identifier syntax. Now all users must start with "user=" 925 prefix. Specified that identifiers starting with a "group=" prefix are 926 reserved for groups and implementation defined aliases. 928 3. Specified that mailbox deletion is controled by the "x" right and 929 EXPUNGE is controlled by "e" right. 931 4. Clarified that RENAME requires "c" right for the new parent and "x" 932 right for the old name. 934 5. Changed capability name from "ACL" to "ACL2" because changes 2 and 3 935 are not backward compatible with ACL RFC. 937 6. Added "t" right that controls STORE \Deleted. Redefined "d" to be a 938 macro for "e", "x" and "t". 940 7. Added "ACL2=UNION" and "ACL2=MOST-SPECIFIC" capabilities and IANA 941 registration template. 943 8. Specified that "a" right also controls DELETEACL 945 9. Specified that "r" right also controls STATUS 947 10. Specified that "w" controls setting flags other than \Seen and \Deleted 948 on APPEND. Same for "s" and "t" flags. 950 11. Specified that "l" controls SUBSCRIBE/UNSUBSCRIBE. 952 12. Added note about compatibility with RFC 2086 954 13. Added "Implementation Notes" section. 956 14. Updated "References" section. 958 15. Deleted "PARTIAL", this is a depricated feature of RFC1730. 960 16. Added MYRIGHT response code as per Cyrus suggestion. 962 17. Added REPLACEACL (ACL SET) as per Mark and Cyrus request. 964 18. Added new section that describes which rights are required and/or 965 checked when performing various IMAP commands. 967 19. Added section about interaction of ACL2 with the QUOTA extension. 969 20. Added special identifiers "authuser", "owner" and "administrators". 971 21. Added mail client security considerations when dealing with special 972 identifier "anyone". 974 22. Clarified that negative rights are not the same as DELETEACL (ACL DELETE). 976 23. Removed the requirement to check the "r" right for CHECK, SEARCH and 977 FETCH, as this is required for SELECT/EXAMINE to be successful. 979 24. Added note that a server can modify an ACL for any identifier(s) as a 980 side effect of performing SETACL/DELETEACL/REPLACEACL 981 (ACL STORE/DELETE/SET). Also specified that the server MUST send 982 untagged ACL response if it does that. Updated command definition 983 to include optional ACL untagged response. 985 25. Fixed typo in 10.1. (Was "ACL=...", not "ACL2=...") 987 26. Cleaned up section 10.2 a bit. 989 27. LISTRIGHTS (ACL LIST) requires same rights as MYRIGHTS. 991 28. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY 992 response codes. 994 29. Changed ABNF for rigths/mod_rights to be quoted instead of astring. 996 30. Changed syntax of ACL2 commands according to the following table: 997 SETACL => ACL STORE 998 DELETEACL => ACL DELETE 999 REPLACEACL => ACL SET 1000 GETACL => ACL GET 1001 LISTRIGHTS => ACL LIST 1003 MYRIGHTS was left as is 1005 Changed syntax of ACL2 responses: 1006 ACL => ACLINFO 1007 LISTRIGHTS => RIGHTS-INFO 1009 MYRIGHTS was left as is 1011 Any better suggestions for names are welcome. 1013 31. Added mailbox patterns and partial failures. Updated ABNF. 1015 To Do List: 1017 1). Cleanup appendix A before publication as RFC, as some changes don't 1018 apply to RFC 2086.