idnits 2.17.1 draft-ietf-imapext-acl-05.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 985 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 127 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 (June 2002) is 7979 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: 'UNSEEN 12' is mentioned on line 770, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 771, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 772, but not defined == Unused Reference: 'UTF-8' is defined on line 795, but no explicit reference was found in the text == Unused Reference: 'QUOTA' is defined on line 798, 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 (==), 2 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-05.txt June 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 4. Commands 337 4.1. ACL STORE 339 Arguments: mailbox name 340 authentication identifier 341 access right modification 343 Data: OPTIONAL untagged responses: ACLINFO 345 Result: OK - ACL STORE completed 346 NO - ACL STORE failure: can't set acl 347 BAD - command unknown or arguments invalid 349 The ACL STORE command changes the access control list on the 350 specified mailbox so that the specified identifier is granted 351 permissions as specified in the third argument. 353 The third argument is a string containing an optional plus ("+") 354 or minus ("-") prefix, followed by zero or more rights characters. 355 If the string starts with a plus, the following rights are added 356 to any existing rights for the identifier. If the string starts 357 with a minus, the following rights are removed from any existing 358 rights for the identifier. If the string does not start with a 359 plus or minus, the rights replace any existing rights for the 360 identifier. 362 Note, that for "ACL2=UNION" access calculation rule 363 MUST be treated as 364 . Also note that these two commands 365 don't have the same result for "ACL2=MOST-SPECIFIC". 367 An ACL2 server MAY modify one or more ACL for one or more identifier 368 as a side effect of modifying the ACL specified in ACL STORE. If the 369 server does that it MUST send untagged ACLINFO response to notify the 370 client about the changes made. 372 4.2. ACL DELETE 374 Arguments: mailbox name 375 authentication identifier 377 Data: OPTIONAL untagged responses: ACLINFO 379 Result: OK - ACL DELETE completed 380 NO - ACL DELETE failure: can't delete acl 381 BAD - command unknown or arguments invalid 383 The ACL DELETE command removes any pair for the 384 specified identifier from the access control list for the 385 specified mailbox. 387 An ACL2 server MAY modify one or more ACL for one or more identifier 388 as a side effect of modifying the ACL specified in ACL DELETE. If the 389 server does that it MUST send untagged ACLINFO response to notify the 390 client about the changes made. 392 4.3. ACL SET 394 Arguments: mailbox name 395 list of (authentication identifier, access rights) pairs 397 Data: OPTIONAL untagged responses: ACLINFO 399 Result: OK - replaceacl completed 400 NO - replaceacl failure: can't replace acl 401 BAD - command unknown or arguments invalid 403 The ACL SET command replaces the access control list of the 404 specified mailbox with the one provided as the second parameter to 405 ACL SET. This command is semantically equivalent to the following 406 sequence of commands: 408 1). ACL GET 409 2). For each (authentication identifier AID, access rights RD) pair returned 410 in the untagged ACL response that was caused by ACL GET, perform 411 ACL DELETE AID 412 3). For each (authentication identifier AIA, access rights RA) pair from 413 the second parameter of ACL SET perform 414 ACL STORE AIA RA 416 An ACL2 server MAY modify one or more ACL for one or more identifier 417 as a side effect of modifying the ACL specified in ACL SET. If the 418 server does that it MUST send untagged ACLINFO response to notify the 419 client about the changes made. 421 4.4. ACL GET 423 Arguments: mailbox name 425 Data: REQUIRED untagged responses: ACLINFO 427 Result: OK - ACL GET completed 428 NO - ACL GET failure: can't get acl 429 BAD - command unknown or arguments invalid 431 The ACL GET command returns the access control list for mailbox in 432 an untagged ACLINFO reply. 434 Example: C: A002 ACL GET INBOX 435 S: * ACLINFO INBOX user=Fred rwipslextda 436 S: A002 OK acl get complete 438 4.5. ACL LIST 440 Arguments: mailbox name 441 authentication identifier 443 Data: untagged responses: RIGHTS-INFO 445 Result: OK - ACL LIST completed 446 NO - ACL LIST failure: can't get rights list 447 BAD - command unknown or arguments invalid 449 The ACL LIST command takes a mailbox name and an identifier and 450 returns information about what rights may be granted to the 451 identifier in the ACL for the mailbox. 453 Example: C: a001 ACL LIST ~/Mail/saved user=smith 454 S: * RIGHTS-INFO ~/Mail/saved user=smith la r swi cdext 455 S: a001 OK ACL LIST completed 457 C: a005 ACL LIST archive.imap anyone 458 S: * RIGHTS-INFO archive.imap anyone "" l r s w i p c dtex a 459 0 1 2 3 4 5 6 7 8 9 460 S: a005 OK ACL LIST completed 462 4.6. MYRIGHTS 464 Arguments: mailbox name 466 Data: untagged responses: MYRIGHTS 468 Result: OK - myrights completed 469 NO - myrights failure: can't get rights 470 BAD - command unknown or arguments invalid 472 The MYRIGHTS command returns the set of rights that the user has 473 to mailbox in an untagged MYRIGHTS reply. 475 < as well.>> 490 The user must have any of the following rights to perform this operation: 491 "l", "r", "i", "c", "x", "e", "a". 492 If the user doesn't have any right from the above list, the server 493 MUST behave as if the mailbox doesn't exist. 495 Example: C: A003 MYRIGHTS INBOX 496 S: * MYRIGHTS INBOX rwipsldexta 497 S: A003 OK Myrights complete 499 5. Responses 501 5.1. ACLINFO 503 Data: mailbox name 504 zero or more identifier rights pairs 506 The ACLINFO response occurs as a result of a ACL GET command. It MAY 507 also occur as a result of ACL STORE/DELETE/SET. The first string 508 is the mailbox name for which this ACL applies. This is followed 509 by zero or more pairs of strings, each pair contains the identifier 510 for which the entry applies followed by the set of rights that the 511 identifier has. 513 << There is a proposal to use LISTEXT syntax instead. This requires 514 publishing a new revision of LISTEXT, that in its current form, is not 515 flexible enough. >> 517 5.2. RIGHTS-INFO 519 Data: mailbox name 520 identifier 521 required rights 522 list of optional rights 524 The RIGHTS-INFO response occurs as a result of a ACL LIST 525 command. The first two strings are the mailbox name and 526 identifier for which this rights list applies. Following the 527 identifier is a string containing the (possibly empty) set of 528 rights the identifier will always be granted in the mailbox. 529 Following this are zero or more strings each containing a set of 530 rights the identifier may be granted in the mailbox. Rights 531 mentioned in the same string are tied together--either all must be 532 granted to the identifier in the mailbox or none may be granted. 534 The same right may not be listed more than once in the RIGHTS-INFO 535 response. 537 5.3. MYRIGHTS untagged response 539 Data: mailbox name 540 rights 542 The MYRIGHTS response occurs as a result of a MYRIGHTS command. 543 The first string is the mailbox name for which these rights apply. 544 The second string is the set of rights that the client has. 546 5.4. MYRIGHTS response code 548 Data: rights 550 The MYRIGHTS response code is sent in an untagged OK response 551 that results from SELECT/EXAMINE. Also this response code can be 552 sent at any time after opening a mailbox when the server detects 553 that the set of rights allowed for the logged in user has changed. 555 The MYRIGHT response code is equivalent to MYRIGHTS untagged response 556 for the selected mailbox. 558 6. Formal Syntax 560 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 561 Non-terminals referenced but not defined below are as defined by 562 [IMAP4]. 564 Except as noted otherwise, all alphabetic characters are 565 case-insensitive. The use of upper or lower case characters to 566 define token strings is for editorial clarity only. Implementations 567 MUST accept these strings in a case-insensitive fashion. 569 acl2_command = myrights | "ACL" SPACE acl2_subcommand 571 acl2_subcommand = replaceacl | deleteacl | updateacl | getacl | listrights 573 acl_data = "ACLINFO" SPACE mailbox *(SPACE identifier SPACE rights) 575 always_granted = rights 577 deleteacl = "DELETE" SPACE mailbox SPACE identifier 579 getacl = "GET" SPACE mailbox 581 identifier = astring 582 ;; UTF-8 584 << Specify more detailed syntax for identifiers? >> 586 listrights = "LIST" SPACE mailbox SPACE identifier 588 listrights_data = "RIGHTS-INFO" SPACE mailbox SPACE identifier 589 SPACE always_granted *(SPACE rights) 591 mod_rights = quoted 592 ;; +rights to add, -rights to remove 594 myrights = "MYRIGHTS" SPACE mailbox 596 myrights_data = "MYRIGHTS" SPACE mailbox SPACE rights 598 myrights_rspcod = "MYRIGHTS" SPACE rights 600 replaceacl = "SET" SPACE mailbox *(SPACE identifier SPACE rights) 602 resp-text-code =/ myrights_data 604 rights = quoted 605 ;; MUST NOT contain leading "+" or "-" 607 updateacl = "STORE" SPACE mailbox SPACE identifier SPACE mod_rights 609 7. IANA considerations 611 7.1. ACL access calculation rule Registration Template 613 When an access calculation rule for ACL2 extension is registered, the 614 following information is supplied: 616 Rule Identification: specify a string that identifies this 617 rule. Unless the rule is registered with the IANA, the 618 rule's identification must start with "X-". 619 The server supporting a particular rule MUST report 620 "ACL2=" in the capability list. 622 Rule Semantics: specify how access rights for a mailbox are calculated. 624 Negative rights allowed: specify whether "negative right" identifiers are 625 allowed. 627 Groups allowed: specify whether group identifiers are allowed. 629 Special Identifiers: describe whether any implementation defined 630 aliases are allowed and define their meaning. 632 Contact Information: specify the postal and electronic contact 633 information for the author of the feature. 635 8. Initial Registrations 637 8.1. Registration: UNION access calculation rule 639 Rule Identification: UNION 641 Rule Semantics: the union of the rights granted to 642 the applicable identifiers minus the union of the negative rights. 644 Negative rights allowed: Yes. 646 Groups allowed: Yes, but not required. 648 Special Identifiers: No. 650 Contact Information: c.f., the "Editor's Address" section of this 651 memo 653 8.2. Registration: MOST-SPECIFIC access calculation rule 655 Rule Identification: MOST-SPECIFIC 657 Rule Semantics: the rights granted to the most specific identifier 658 present in the ACL are used, i.e. if the user identifier is present, 659 its ACL is used. If no user identifier is present, but a group that 660 includes this user as a member is present, the group ACL is used. 661 If neither user, nor group identifier is present, but an ACL for 662 a special group "anyone" is present, the ACL for "anyone" is used. 664 Negative rights allowed: No. 666 Groups allowed: Yes, but not required. 668 Special Identifiers: No. 670 Contact Information: c.f., the "Editor's Address" section of this 671 memo 673 9. Security Considerations 675 An implementation must make sure the ACL commands themselves do not 676 give information about mailboxes with appropriately restricted ACL's. 677 For example, a ACL GET command on a mailbox for which the user has 678 insufficient rights should not admit the mailbox exists, much less 679 return the mailbox's ACL. 681 IMAP clients implementing ACL2 that are able to modify ACLs SHOULD 682 warn a user that wants to give full access to the special identifier 683 "anyone". 685 10. Other considerations 687 10.1. Compatibility with RFC 2086 689 << This has to be written >> 691 10.2. ACL2 interaction with QUOTA extension 693 Server that implement both ACL2 and QUOTA extensions MUST use the following 694 table to determine if a quote operation should be allowed for the user: 696 GETQUOTAROOT - "r" right 697 << Replace with/add "a" and "i"? >> 699 GETQUOTA - no rights required 701 SETQUOTA - implementation defined, as SETQUOTA operates on a quotaroot, 702 not on a mailbox. 704 10.3. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes. 706 A particular ACL2 server implementation may allow "shared multiuser 707 access" to some mailboxes. "Shared multiuser access" to a mailbox means 708 that multiple different users are able to access the same mailbox, 709 if they have proper access rights. "Shared multiuser access" to the 710 mailbox doesn't mean that the ACL for the mailbox is currently set 711 to allow access by multiple users. Let's denote a "shared multiuser 712 write access" as a "shared multiuser access" when a user may be 713 granted flag modification rights (any of "w", "s" or "t"). 715 Section 3.1 ("Rights required to perform different IMAP4rev1 commands") 716 describes which rights are required for modifying different flags. 718 If the ACL2 server implements some flags as shared for a mailbox (i.e., 719 the ACL for the mailbox may be set up so that changes to those flags are 720 visible to another user), let's call the set of rights associated with these 721 flags (as described in 3.1) for that mailbox collectively as "shared flag 722 rights". Note, that "shared flag rights" set MAY be different for different 723 mailboxes. 725 If the server doesn't support "shared multiuser write access" to a 726 mailbox or doesn't implement shared flags on the mailbox, "shared flag 727 rights" for the mailbox is defined to be the empty set. 729 Example 1: Mailbox "banan" allows "shared multiuser write access" and 730 implements flags \Deleted, \Answered and $MDNSent as 731 shared flags. "Shared flag rights" for the mailbox "banan" 732 is a set containing flags "t" (because system flag \Deleted 733 requires "t" right) and "w" (because both \Answered and 734 $MDNSent require "w" right). 736 Example 2: Mailbox "apple" allows "shared multiuser write access" and 737 implements \Seen system flag as shared flag. "Shared flag 738 rights" for the mailbox "apple" contains "s" right, 739 because system flag \Seen requires "s" right. 741 Example 3: Mailbox "pear" allows "shared multiuser write access" and 742 implements flags \Seen, \Draft as shared flags. "Shared flag 743 rights" for the mailbox "apple" is a set containing flags "s" 744 (because system flag \Seen requires "s" right) and "w" 745 (because system flag \Draft requires "w" right). 747 <> 750 The server MUST include a READ-ONLY prefix in the tagged OK response to 751 a SELECT command if all of the following rights are not granted to the 752 current user: 753 "i", "e" and "shared flag rights". 754 The server SHOULD include a READ-WRITE prefix in the tagged OK response 755 if either of the "i", "e" or "shared flag rights" is granted to the 756 current user. 758 <> 760 10.4. Additional requirements and Implementation notes 762 Any server implementing an ACL2 extension MUST accurately reflect the current 763 user's rights in FLAGS and PERMANENTFLAGS responses. The server SHOULD issue 764 a MYRIGHTS response code in an untagged OK response as a result of a SELECT 765 or EXAMINE command. 767 Example: C: A142 SELECT INBOX 768 S: * 172 EXISTS 769 S: * 1 RECENT 770 S: * OK [UNSEEN 12] Message 12 is first unseen 771 S: * OK [UIDVALIDITY 3857529045] UIDs valid 772 S: * OK [UIDNEXT 4392] Predicted next UID 773 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 774 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 775 S: * OK [MYRIGHTS rwiste] Allowed rights 776 S: A142 OK [READ-WRITE] SELECT completed 778 An ACL2 server MAY modify one or more ACL for one or more identifier as a 779 side effect of modifying the ACL specified in ACL STORE/DELETE/SET. 780 If the server does that it MUST send untagged ACL response to notify the 781 client about the changes made. 783 11. References 785 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 786 Requirement Levels", RFC 2119, Harvard University, March 1997. 788 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 789 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 790 November 1997. 792 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 793 4rev1", RFC 2060, University of Washington, December 1996. 795 [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", 796 RFC 2279, Alis Technologies, January 1998. 798 [QUOTA] Myers, J., "IMAP4 QUOTA extension", RFC 2087, Carnegie Mellon 799 University, January 1997. 801 12. Aknowledgement 803 This document is a revision of the RFC 2086 written by John G. Myers. 805 Editor appreciates comments received from Mark Crispin, Chris Newman, 806 Cyrus Daboo, John G. Myers, Curtis King, Lyndon Nerenberg, Larry Greenfield, 807 Vladimir Butenko, Dave Cridland and other members of IMAPEXT working group. 809 13. Editor's Address 811 Alexey Melnikov 812 mailto: mel@messagingdirect.com 814 ACI WorldWide/MessagingDirect 815 22 The Quadrant, Richmond, 816 Surrey, United Kingdom, TW9 1BP 818 14. Full Copyright Statement 820 Copyright (C) The Internet Society 2002. All Rights Reserved. 822 This document and translations of it may be copied and furnished to 823 others, and derivative works that comment on or otherwise explain it 824 or assist in its implementation may be prepared, copied, published 825 and distributed, in whole or in part, without restriction of any 826 kind, provided that the above copyright notice and this paragraph 827 are included on all such copies and derivative works. However, this 828 document itself may not be modified in any way, such as by removing 829 the copyright notice or references to the Internet Society or other 830 Internet organizations, except as needed for the purpose of 831 developing Internet standards in which case the procedures for 832 copyrights defined in the Internet Standards process must be 833 followed, or as required to translate it into languages other than 834 English. 836 The limited permissions granted above are perpetual and will not be 837 revoked by the Internet Society or its successors or assigns. 839 This document and the information contained herein is provided on an 840 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 841 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 842 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 843 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 844 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 846 Appendix A. Changes since RFC 2086 848 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 850 2. Changed identifier syntax. Now all users must start with "user=" 851 prefix. Specified that identifiers starting with a "group=" prefix are 852 reserved for groups and implementation defined aliases. 854 3. Specified that mailbox deletion is controled by the "x" right and 855 EXPUNGE is controlled by "e" right. 857 4. Clarified that RENAME requires "c" right for the new parent and "x" 858 right for the old name. 860 5. Changed capability name from "ACL" to "ACL2" because changes 2 and 3 861 are not backward compatible with ACL RFC. 863 6. Added "t" right that controls STORE \Deleted. Redefined "d" to be a 864 macro for "e", "x" and "t". 866 7. Added "ACL2=UNION" and "ACL2=MOST-SPECIFIC" capabilities and IANA 867 registration template. 869 8. Specified that "a" right also controls DELETEACL 871 9. Specified that "r" right also controls STATUS 873 10. Specified that "w" controls setting flags other than \Seen and \Deleted 874 on APPEND. Same for "s" and "t" flags. 876 11. Specified that "l" controls SUBSCRIBE/UNSUBSCRIBE. 878 12. Added note about compatibility with RFC 2086 880 13. Added "Implementation Notes" section. 882 14. Updated "References" section. 884 15. Deleted "PARTIAL", this is a depricated feature of RFC1730. 886 16. Added MYRIGHT response code as per Cyrus suggestion. 888 17. Added REPLACEACL (ACL SET) as per Mark and Cyrus request. 890 18. Added new section that describes which rights are required and/or 891 checked when performing various IMAP commands. 893 19. Added section about interaction of ACL2 with the QUOTA extension. 895 20. Added special identifiers "authuser", "owner" and "administrators". 897 21. Added mail client security considerations when dealing with special 898 identifier "anyone". 900 22. Clarified that negative rights are not the same as DELETEACL (ACL DELETE). 902 23. Removed the requirement to check the "r" right for CHECK, SEARCH and 903 FETCH, as this is required for SELECT/EXAMINE to be successful. 905 24. Added note that a server can modify an ACL for any identifier(s) as a 906 side effect of performing SETACL/DELETEACL/REPLACEACL 907 (ACL STORE/DELETE/SET). Also specified that the server MUST send 908 untagged ACL response if it does that. Updated command definition 909 to include optional ACL untagged response. 911 25. Fixed typo in 10.1. (Was "ACL=...", not "ACL2=...") 913 26. Cleaned up section 10.2 a bit. 915 27. LISTRIGHTS (ACL LIST) requires same rights as MYRIGHTS. 917 28. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY 918 response codes. 920 29. Changed ABNF for rigths/mod_rights to be quoted instead of astring. 922 30. Changed syntax of ACL2 commands according to the following table: 923 SETACL => ACL STORE 924 DELETEACL => ACL DELETE 925 REPLACEACL => ACL SET 926 GETACL => ACL GET 927 LISTRIGHTS => ACL LIST 929 MYRIGHTS was left as is 931 Changed syntax of ACL2 responses: 932 ACL => ACLINFO 933 LISTRIGHTS => RIGHTS-INFO 935 MYRIGHTS was left as is 937 Any better suggestions for names are welcome. 939 To Do List: 941 1). Cleanup appendix A before publication as RFC, as some changes don't 942 apply to RFC 2086. 944 2). Editorial: Convert to nroff, Word or XML format. 946 3). Update syntax to allow for multiple mailboxes and masks. 947 Describe partial failures.