idnits 2.17.00 (12 Aug 2021) /tmp/idnits20673/draft-ietf-imapext-acl-10.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): ---------------------------------------------------------------------------- ** 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 1104. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1140. ** 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 1329 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 219 instances of too long lines in the document, the longest one being 19 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 (July 2004) is 6512 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: 'EXT' is mentioned on line 718, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 1049, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 1050, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 1051, but not defined == Unused Reference: 'UTF-8' is defined on line 1074, 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 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) == Outdated reference: draft-ietf-imapext-list-extensions has been published as RFC 5258 Summary: 18 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMAPEXT Working Group A. Melnikov 3 Internet Draft Editor 4 Document: draft-ietf-imapext-acl-10.txt July 2004 5 Expires: January 2005 7 IMAP4 ACL extension 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, or 13 will be disclosed, and any of which I become aware will be disclosed, 14 in accordance with RFC 3668. 16 Internet Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its Areas, and its Working Groups. Note that 18 other groups may also distribute working documents as Internet 19 Drafts. Internet Drafts are draft documents valid for a maximum of 20 six months. Internet Drafts may be updated, replaced, or obsoleted 21 by other documents at any time. It is not appropriate to use 22 Internet Drafts as reference material or to cite them other than as 23 ``work in progress''. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 32 munnari.oz.au. 34 A revised version of this draft document will be submitted to the RFC 35 editor as a Proposed Standard for the Internet Community. Discussion 36 and suggestions for improvement are requested. Distribution of this 37 draft is unlimited. 39 0. Open issues and ToDo list 41 This section will be removed when the draft will be published as RFC. 42 It is intended to simplify discussion. 44 1). Require support for special identifier "disabled" for 45 "ACL2=MOST-SPECIFIC" model? Can the same result be achieved with 46 ? 48 2). Do we need a special command for inserting at 49 any position (this is meaningless for the MOST-SPECIFIC model only). 51 3). IANA registry for prefix in identifiers? 53 4). Do we need the following functionality: discover the set of rights 54 which may be granted to a given identifier in the ACL for a given 55 mailbox? 57 5). Cleanup appendix A before publication as RFC, as some changes don't 58 apply to RFC 2086. 60 6). Other editorial comments/questions are enclosed in << and >>. 62 Table of Contents 63 1 Abstract .................................................. X 64 2 Conventions Used in this Document ......................... X 65 3 Introduction and Overview ................................. X 66 3.1 Access Control ........................................... X 67 3.2 Access calculation model ................................. X 68 3.3 Rights required to perform different IMAP4rev1 commands .. X 69 4 ACL manipulation commands ................................. X 70 4.1 ACL STORE ................................................ X 71 4.2 ACL DELETE ............................................... X 72 4.3 ACL SET .................................................. X 73 4.4 LIST with the ACL parameter .............................. X 74 4.5 LIST with the MYRIGHTS parameter ......................... X 75 5 ACL related responses ..................................... X 76 5.1 Extended LIST response with ACL information .............. X 77 5.2 RIGHTS-INFO .............................................. X 78 5.3 ACLFAILED untagged response .............................. X 79 5.4 Extended LIST response with MYRIGHTS information ......... X 80 5.5 MYRIGHTS response code ................................... X 81 6 Formal Syntax ............................................. X 82 7 IANA considerations ....................................... X 83 7.1 ACL access calculation rule Registration Template ........ X 84 7.2 Initial Registrations .................................... X 85 7.2.1 Registration: UNION access calculation rule ............ X 86 7.2.2 Registration: MOST-SPECIFIC access calculation rule .... X 87 8 Security Considerations ................................... X 88 9 Other considerations ...................................... X 89 9.1 Compatibility with RFC 2086 .............................. X 90 9.2 Mapping of ACL rights to READ-WRITE and READ-ONLY 91 response codes ........................................... X 92 9.4 Additional requirements and Implementation notes ......... X 93 10 Normative References ..................................... X 94 11 Informative References ................................... X 95 12 Aknowledgement ........................................... X 96 13 Editor's Address ......................................... X 97 14 Full Copyright Statement ................................. X 99 1. Abstract 101 The ACL (Access Control List) extension of the Internet Message Access 102 Protocol [IMAP4] permits mailbox access control lists to be manipulated 103 through the IMAP protocol. 105 2. Conventions Used in this Document 107 In examples, "C:" and "S:" indicate lines sent by the client and 108 server respectively. 110 In all examples "/" character is used as hierarchy separator. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 116 3. Introduction and Overview 118 The ACL (Access Control List) extension of the Internet Message Access 119 Protocol [IMAP4] permits mailbox access control lists to be retrieved 120 and manipulated through the IMAP protocol. 122 The ACL extension is present in any IMAP4 implementation which 123 returns a capability starting with "ACL2=" prefix as one of the 124 supported capabilities to the CAPABILITY command. The prefix is 125 followed by "rule identifier" as described in 7.1. 127 <> 129 The document contains the following parts: section 3.1 provides the 130 definition of different classes of identifiers and defines standard 131 rights; section 3.2 introduces access calculation model, i.e. it 132 describes how to calculate from an ACL which rigths apply to a particular 133 user; section 3.3 summarizes relationship of different access rights with 134 IMAP commands; section 4 introduces new IMAP commands the client can use 135 to manipulate ACLs; section 5 defines new ACL related responses; and 136 section 9 lists important considerations for compatibility with [IMAP4], 137 RFC 2086 and some IMAP extensions. 139 3.1. Access Control 141 An access control list is an ordered list of pairs. 142 An ACL applies to a mailbox. 144 Identifier is a UTF-8 string. An identifier may have one of the following 145 forms: 146 a). "anonymous" - special group that refers to the universal identity 147 (all authentications, including anonymous). A special identifier 148 "anyone" is a synonym for the "anonymous". 149 b). "authuser" - special group that refer to all authenticated users, 150 but not anonymous. 151 c). "owner" - special user identifier that refers to the owner of a mailbox 152 (if any). 153 d). "administrators" - special group that refers to all users with 154 administrative rights for the server. 155 e). "user=" - refers to a user. Here "" is a user name 156 string accepted by the LOGIN or AUTHENTICATE commands. 157 f). "group=" - refers to a group. Here "" is a group 158 name. 159 g). "vendor=." - refers to a vendor specific special 160 identifier, not covered by a).-f). 161 h). "-", where is one of a).-g). This is 162 reserved for "negative rights", described below. 164 Note, that a server is not required to implement any special identifier mentioned 165 above. However if it allows a user to perform ACL operations on any one of them, 166 server MUST use the semantic as described above. 168 Also note, that this document doesn't define how groups and administrators 169 are managed. 171 All other identifier names are reserved for future definition in an 172 extension or revision to this specification (also known as ACL2). 174 Rights is a string listing a (possibly empty) set of alphanumeric 175 characters, each character listing a set of operations which is being 176 controlled. Letters are reserved for ''standard'' rights, listed 177 below. The set of standard rights may only be extended by a 178 standards-track document. Digits are reserved for implementation or 179 site defined rights. The currently defined standard rights are: 181 l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox) 182 r - read (SELECT the mailbox, perform STATUS, CHECK, FETCH, SEARCH, 183 COPY from mailbox) 184 s - keep seen/unseen information across sessions (set or clear \SEEN flag 185 via STORE, APPEND or COPY) 186 w - write (set or clear flags other than \SEEN and \DELETED via STORE, 187 APPEND or COPY) 188 i - insert (perform APPEND, COPY into mailbox) 189 p - post (send mail to submission address for mailbox, 190 not enforced by IMAP4 itself. 191 c - create mailboxes (CREATE new sub-mailboxes in any 192 implementation-defined hierarchy, parent mailbox for the new 193 mailbox name in RENAME) 194 When a new mailbox is created it SHOULD inherit rights from 195 the parent mailbox (if one exists) in the defined hierarchy. 196 x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) 197 t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag 198 during APPEND/COPY) 199 e - perform EXPUNGE and expunge as a part of CLOSE 200 d - This right is defined for backward compatibility with ACL 201 extension (RFC 2086). If a client sets "d" right, the server MUST 202 set "x", "e" and "t" rights. When the client clears the "d" right, 203 the server MUST clear "x", "e" and "t" rights. When all three of "x", 204 "e" and "t" are set, the server MUST return "d" right in response to 205 a LIST (ACL) command. If "x", "e" and "t" rights are not tied together, 206 "d" right MUST NOT be returned in a RIGHTS-INFO response. 207 a - administer (perform ACL STORE, ACL SET and ACL DELETE) 209 An implementation may tie rights together or may force rights to 210 always or never be granted to particular identifiers. For example, 211 in an implementation that uses unix mode bits, the rights "swite" are 212 tied, the "a" right is always granted to the owner of a mailbox and 213 is never granted to another user. If rights are tied in an 214 implementation, the implementation must be conservative in granting 215 rights in response to ACL STORE commands--unless all rights in a tied 216 set are specified, none of that set should be included in the ACL 217 entry for that identifier. If the server fails an ACL modification 218 command (ACL STORE or ACL SET) because some rights are tied, it MUST 219 return RIGHTS-INFO untagged response (see section 5.2). 221 When an identifier in an ACL starts with a dash ("-"), that indicates 222 that associated rights are to be removed from the identifier that is 223 prefixed by the dash. This is referred to as a "negative right". 224 This differs from ACL DELETE in that a negative right is added to the 225 ACL, and is part of the calculation of the rights. 227 For example, if the identifier "-user=fred" is granted the "w" right, 228 that indicates that the "w" right is to be removed from users matching 229 the identifier "user=fred", even though the user "fred" might have 230 the "w" right as a consequence of some other identifier in the ACL. 231 A ACL DELETE of "user=fred" simply deletes the identifier "user=fred" 232 from the ACL; it does not affect any rights that the user "fred" 233 may get from another ACL. 235 Server implementations are not required to support "negative right" 236 identifiers. 238 3.2. Access calculation model 240 It is possible for multiple identifiers in an access control list to 241 apply to a given user (or other authentication identity). For 242 example, an ACL may include rights to be granted to the identifier 243 matching the user, one or more implementation-defined identifiers 244 matching groups which include the user, and/or the identifier 245 "anyone". How these rights are combined to determine the user's 246 access is implementation-defined. The set of rules that describes 247 how access is calculated is defined by a rule identifier (rule-ID). 248 This document doesn't define any commands for manipulating a group 249 membership. 251 A client may determine the set of rights granted to the logged-in user 252 for a given mailbox by using the LIST (MYRIGHTS) command. 254 This document defines two initial access calculation models: UNION and 255 MOST-SPECIFIC. 257 If a server implementing ACL2 uses the union of the rights granted to 258 the applicable identifiers minus the union of the negative rights 259 in order to calculate access, it MUST report "ACL2=UNION" in the server's 260 capability list. See also section 7.2.1. 262 An implementation may instead choose to only use those rights granted 263 to the most specific identifier present in the ACL. In this case the 264 server MUST report "ACL2=MOST-SPECIFIC" in the server's capability 265 list. See also section 7.2.2. 267 If the server implements any other policy for rights calculation, 268 it MUST be either registered with IANA using the template provided in 7.1 269 or start with "X-". The server MUST report one and only one "ACL2=" 270 capability in its CAPABILITY response. 272 3.3. Rights required to perform different IMAP4rev1 commands 274 Before executing a command an ACL2 compliant server must check which rights 275 are required to perform it. This section groups command by functions 276 they perform and list the rights required. It also gives the detailed 277 description of any special processing required. 279 The table below summarizes different rights or their combinations that are 280 required in order to perform different IMAP operations. As it is not always 281 possible to express complex right checking and interactions, the description 282 after the table should be used as the primary reference. 284 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 285 | Operations\Rights | l | r | s | w | i | c | x | t | e | a | Any | None | 286 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 287 | LIST | + | | | | | | | | | | | | 288 | SUBSCRIBE | * | | | | | | | | | | | * | 289 | UNSUBSCRIBE | | | | | | | | | | | | + | 290 | LSUB | * | | | | | | | | | | | * | 291 | CREATE (for parent) | | | | | | + | | | | | | | 292 | DELETE | | | | | | | + | | | | | | 293 | RENAME | | | | | | + | + | | | | | | 294 | COPY/APPEND | | | ? | ? | + | | | ? | | | | | 295 | EXPUNGE/CLOSE | | | | | | | | | + | | | | 296 |SELECT/EXAMINE/STATUS| | | | | | | | | | | | | 297 | FETCH | | | ? | | | | | | | | | | 298 | STORE flags | | | ? | ? | | | | ? | | | | | 299 |ACL STORE/DELETE/SET | ? | | | | | | | | | + | | | 300 | LIST (ACL) | ? | | | | | | | | | + | | | 301 | LIST (MYRIGHTS)| | | | | | | | | | | + | | 302 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 304 Legend: 305 + - The right is required 306 * - Only one of the rights marked with * is required (see description below) 307 ? - The right is optional (see description below) 308 "Any" - at least one of the "l", "r", "i", "c", "x", "e", "a" rights is 309 required 310 "None" - No rights required to perform the command 312 Listing and subscribing/unsubscribing mailboxes: 313 LIST - "l" right is required. 315 Note, that if the user has "l" right to a mailbox "A/B", but not to its parent 316 mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist, 317 for example: 318 C: A777 LIST "" * 319 S: * LIST (\NoInferiors) "/" "A/B" 320 S: * LIST () "/" "C" 321 S: * LIST (\NoInferiors) "/" "C/D" 322 S: A777 OK LIST completed 324 SUBSCRIBE - "l" right is required only if the server checks for mailbox existence 325 when performing SUBSCRIBE. 327 UNSUBSCRIBE - no rights required to perform this operation. 329 LSUB - "l" right is required only if the server checks for mailbox existence when 330 performing SUBSCRIBE. 332 Mailbox management: 333 CREATE - "c" right on a nearest existing parent mailbox. When a new mailbox 334 is created it SHOULD inherit rights from the parent mailbox 335 (if one exists) in the defined hierarchy. 337 DELETE - "x" right on the mailbox. 339 RENAME - Moving a mailbox from one parent to another 340 requires "x" right on the mailbox itself and "c" right for the new parent. 341 For example, if the user wants to rename mailbox named "A/B/C" 342 to "D/E", the user must have "x" right 343 for the mailbox "A/B/C" and "c" right for the mailbox "D". 345 Copying or appending messages: 347 Before performing a COPY/APPEND command the server MUST check if the user has "i" right 348 for the target mailbox. If the user doesn't have "i" right, the operation fails. 349 Otherwise for each copied/appended message the server MUST check if the user has 350 "t" right - when the message has \Deleted flag set 351 "s" right - when the message has \Seen flag set 352 "w" right for all other message flags. 353 Only when the user has a particular right the corresponding flags are stored for the 354 newly created message. The server MUST NOT fail a COPY/APPEND if the user has no rights 355 to set a particular flag. 357 Example: C: A003 LIST (MYRIGHTS) "" TargetMailbox 358 S: * LIST () "/" TargetMailbox (("MYRIGHTS" "rwis")) 359 S: A003 OK Myrights complete 361 C: A004 FETCH 1:3 (FLAGS) 362 S: * 1 FETCH (FLAGS (\Draft \Deleted) 363 S: * 2 FETCH (FLAGS (\Answered) 364 S: * 3 FETCH (FLAGS ($Forwarded \Seen) 365 S: A004 OK Fetch Completed 367 C: A005 COPY 1:3 TargetMailbox 368 S: A005 OK Copy completed 370 C: A006 SELECT TargetMailbox 371 ... 372 S: A006 Select Completed 374 Let's assume that the copied messages received message numbers 77:79. 376 C: A007 FETCH 77:79 (FLAGS) 377 S: * 77 FETCH (FLAGS (\Draft)) 378 S: * 78 FETCH (FLAGS (\Answered)) 379 S: * 79 FETCH (FLAGS ($Forwarded \Seen)) 380 S: A007 OK Fetch Completed 382 \Deleted flag was lost on COPY, as the user has no "t" right in the 383 target mailbox. 385 If the LIST (MYRIGHT) command with the tag A003 would have returned: 386 S: * LIST () "/" TargetMailbox (("MYRIGHTS" "rsti")) 388 the response from the FETCH with the tag A007 would have been: 390 C: A007 FETCH 77:79 (FLAGS) 391 S: * 77 FETCH (FLAGS (\Deleted)) 392 S: * 78 FETCH (FLAGS ()) 393 S: * 79 FETCH (FLAGS (\Seen)) 394 S: A007 OK Fetch Completed 396 In the latter case \Answered, $Forwarded and \Draft flags were lost 397 on COPY, as the user has no "w" right in the target mailbox. 399 Expunging the selected mailbox: 400 EXPUNGE - "e" right on the selected mailbox. 402 CLOSE - "e" right on the selected mailbox. If the server is unable to 403 expunge the mailbox because the user doesn't have the "e" right, 404 the server MUST ignore expunge request, close the mailbox 405 and return tagged OK response. 407 Fetch information about a mailbox and its messages: 408 SELECT/EXAMINE/STATUS - "r" right on the mailbox. 410 FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it, 411 if the current user doesn't have "s" right. 413 Changing flags: 414 STORE - the server MUST check if the user has 415 "t" right - when the user modifies \Deleted flag 416 "s" right - when the user modifies \Seen flag 417 "w" right for all other message flags. 418 STORE operation SHOULD NOT fail if the user has rights to modify at least 419 one flag specified in the STORE. 421 Changing ACLs: 422 ACL STORE/DELETE/SET - "a" right on the mailbox (*). 424 Reading ACLs: 425 LIST (ACL) - "a" right on the mailbox (*). 427 LIST (MYRIGHTS) - any of the following rights is required to perform 428 the operation: "l", "r", "i", "c", "x", "e", "a". 430 (*) Note, that when one or more mailbox pattern is specified, 431 'l' right is required for each mailbox matching the mailbox pattern(s). 433 4. ACL manipulation commands 435 All ACL commands (i.e. ACL STORE/DELETE/SET) 436 accept either a single mailbox name or several mailbox patterns as a 437 parameter. Mailbox pattern is a mailbox with wildcards, wildcards are 438 interpreted as described in [IMAP4] LIST command. In order to distinguish 439 between a mailbox name (that is allowed to have wildcard characters '*' 440 and '%') and a mailbox pattern, the latter is always represented as a 441 parenthesized list. 443 For simplicity the behaviour of ACL STORE/DELETE/SET commands 444 is described for a single mailbox case. When one or more mailbox pattern 445 is specified, the server internally performs LIST command for all specified 446 patterns and than it combines the results. Note, that only mailboxes for 447 which the user has 'l' right are included in the combined result. If the 448 combined result has no mailboxes, an ACL operation completes with success 449 and the tagged OK response is sent. Otherwise the requested operation is 450 performed for each mailbox in the combined result. If a particular mailbox 451 causes the operation to fail (e.g. insufficient permissions), instead of 452 failing the whole command, an untagged ACLFAILED or RIGHTS-INFO response 453 is sent for this mailbox and the operation continues for the rest of the 454 mailboxes. If the server knows that the operation will fail in the same 455 manner for all matching mailboxes (e.g. user doesn't exist), it SHOULD 456 return tagged NO response instead of sending several untagged ACLFAILED 457 responses. 459 Example: 461 In the example below ACL SET command fails for 2 mailboxes 462 "Personal/Jokes" and "Personal/Deaf and Blind". For the latter a human 463 readable error description is returned. Also, the ACL for the mailbox 464 "Personal/Secret" was updated to include the "r" right for a user 465 "user=Boss" as a side effect of the ACL SET command (see also 4.3). 467 C: A002 ACL SET (INBOX Personal/*) user=Fred rwist 468 S: * ACLFAILED Personal/Jokes 469 S: * ACLFAILED "Personal/Deaf and Blind" Temporary Error 470 S: * LIST () "/" Personal/Secret (("ACL" (("user=Boss" "r")))) 471 S: A002 OK acl set completed 473 Example: C: A002 ACL SET (Fruits/Apples/*) user=Zak lrs 474 S: A002 NO User Zak doesn't exist 476 4.1. ACL STORE 478 Arguments: mailbox name or one or more mailbox masks 479 authentication identifier 480 access right modification 482 Data: OPTIONAL untagged responses: LIST with ACL information (see 5.1) 484 Result: OK - ACL STORE completed 485 NO - ACL STORE failure: can't set acl 486 BAD - command unknown or arguments invalid 488 The ACL STORE command changes the access control list on the 489 specified mailbox so that the specified identifier is granted 490 permissions as specified in the third argument. 492 The third argument is a string containing an optional plus ("+") 493 or minus ("-") prefix, followed by zero or more rights characters. 494 If the string starts with a plus, the following rights are added 495 to any existing rights for the identifier. If the string starts 496 with a minus, the following rights are removed from any existing 497 rights for the identifier. If the string does not start with a 498 plus or minus, the rights replace any existing rights for the 499 identifier. The combined rights will be called the "resulting" rights. 501 If before execution of the command the identifier is not present 502 in the ACL, the pair is added to the end of 503 the ACL. Otherwise it replaces the rights for the identifier, 504 with the resulting rights. Note, that for the "ACL2=UNION" access 505 calculation model the rule MUST 506 be treated as . Also note that these 507 two commands don't have the same result for the "ACL2=MOST-SPECIFIC" 508 access calculation model. 510 An ACL2 server MAY modify one or more ACL for one or more identifier 511 ("additional modifications") as a side effect of modifying the ACL 512 specified in ACL STORE. For example, in some mail stores, a mailbox can 513 be a member of only one group. For such mailstore, doing an ACL STORE 514 that sets a different group from what is already in the ACL MAY have 515 the effect of doing an implicit ACL DELETE of the existing group's 516 identifier/rights pair. If the server does additional modification 517 it MUST send untagged LIST response with ACL information (see section 5.1) 518 to notify the client about the changes made. 520 If the server is unwilling to perform the command, because some rights 521 for the identifier are tied, it MUST return RIGHTS-INFO untagged response 522 (see section 5.2). 524 Example: C: A002 ACL STORE ~/Mail/saved user=smith cp 525 S: * RIGHTS-INFO ~/Mail/saved user=smith la r swi cdext p 526 S: A002 NO Acl store failed, some rights are tied 528 Client decides to grant both rights to the identifier: 530 C: A003 ACL STORE ~/Mail/saved user=smith cdextp 531 S: A003 OK Setacl complete 533 The following example demonstrates behaviour of a mail store that allows 534 a mailbox to be a member of only one group: 536 C: B001 LIST (ACL) "" INBOX 537 S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") ( 538 "group=Devel" "rwipslt")))) 539 S: B001 OK List with acl info completed 540 C: B002 ACL STORE Inbox group=PSO rwipslte 541 S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda") ( 542 "group=PSO" "rwipslte")))) 543 S: B002 OK Setacl complete 545 4.2. ACL DELETE 547 Arguments: mailbox name or one or more mailbox masks 548 authentication identifier 550 Data: OPTIONAL untagged responses: LIST with ACL information (see 5.1) 552 Result: OK - ACL DELETE completed 553 NO - ACL DELETE failure: can't delete acl 554 BAD - command unknown or arguments invalid 556 The ACL DELETE command removes any pair for the 557 specified identifier from the access control list for the 558 specified mailbox. 560 An ACL2 server MAY modify one or more ACL for one or more identifier 561 as a side effect of modifying the ACL specified in ACL DELETE. If the 562 server does that it MUST send untagged LIST response with ACL information 563 (see section 5.1) to notify the client about the changes made. 565 4.3. ACL SET 567 Arguments: mailbox name or one or more mailbox masks 568 list of (authentication identifier, access rights) pairs 570 Data: OPTIONAL untagged responses: LIST with ACL information (see 5.1) 572 Result: OK - replaceacl completed 573 NO - replaceacl failure: can't replace acl 574 BAD - command unknown or arguments invalid 576 The ACL SET command replaces the access control list of the 577 specified mailbox with the one provided as the second parameter to 578 ACL SET. This command is semantically equivalent to the following 579 sequence of commands: 581 1). LIST (ACL) "" 582 2). For each (authentication identifier AID, access rights RD) pair returned 583 in the untagged LIST response that was caused by LIST (ACL), perform 584 ACL DELETE AID 585 3). For each (authentication identifier AIA, access rights RA) pair from 586 the second parameter of ACL SET perform 587 ACL STORE AIA RA 589 An ACL2 server MAY modify one or more ACL for one or more identifier 590 as a side effect of modifying the ACL specified in ACL SET. If the 591 server does that it MUST send untagged LIST response with ACL information 592 (see section 5.1) to notify the client about the changes made. 594 If the server is unwilling to perform the command, because some rights 595 for an identifier from the second list parameter are tied, it MUST 596 return RIGHTS-INFO untagged response (see section 5.2). 598 4.4. LIST with the ACL parameter 600 This document defines a new option ACL to the LIST command that requests 601 the server to return the corresponding ACLs for all mailboxes that 602 match the LIST mailbox name. The ACL option causes the server 603 to return LIST with the ACL information (see 5.1). 605 <> 607 Example: C: A002 LIST (ACL) "" INBOX 608 S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda")))) 609 S: A002 OK List with acl info completed 611 4.5. LIST with the MYRIGHTS parameter 613 This document defines a new option MYRIGHTS to the LIST command that requests 614 the server to return the set of rights that the user has to a mailbox, 615 that matches the LIST mailbox name. The MYRIGHTS option causes the server 616 to return LIST with MYRIGHTS information (see 5.4). 618 The user must have any of the following rights to perform this operation: 619 "l", "r", "i", "c", "x", "e", "a". 620 If the user doesn't have any right from the above list, the server 621 MUST behave as if the mailbox doesn't exist. 623 Example: C: A002 LIST (MYRIGHTS) "" INBOX 624 S: * LIST () "/" INBOX (("MYRIGHTS" "rwipsldexta")) 625 S: A002 OK List with acl info completed 627 5. ACL related responses 629 5.1. Extended LIST response with ACL information 631 Contents: name attributes 632 hierarchy delimiter 633 mailbox name 634 ACL information (zero or more identifier rights pairs) 636 This version of LIST response occurs as a result of an LIST (ACL) command. 637 It MAY also occur as a result of ACL STORE/DELETE/SET. 638 The proposed syntax conforms to the syntax of an extended LIST response 639 as defined by mbox-list-extended ABNF element of [LISTEXT]. 641 The meaning of "name attributes" and "hierarchy delimiter" is described in 642 section 7.2.2 of [IMAP4]. Hierarchy delimiter is followed by a mailbox 643 name which this ACL applies to. This is followed by the extension part that 644 includes "ACL" tag followed by zero or more pairs of strings, each pair 645 contains the identifier followed by the set of rights that the identifier has. 647 <> 649 Example: S: * LIST () "/" INBOX (("ACL" (("user=Fred" "rwipslextda")))) 651 The example above shows that a user Fred is granted "rwipslextda" 652 rights to the mailbox "INBOX". 654 S: * LIST () ":" Drafts (("ACL" 655 (("user=Fred" "rwipslextda") ("group=Devel" "r")))) 657 The example above shows that a user Fred is granted "rwipslextda" 658 rights and a member of a group "Devel" is granted "r" right to 659 the mailbox "Drafts". 661 S: * LIST () NIL Manson (("ACL" NIL)) 663 The example above shows the mailbox "Manson" has an empty ACL. 665 5.2. RIGHTS-INFO 667 Data: mailbox name 668 identifier 669 required rights 670 list of optional rights 672 The RIGHTS-INFO response occurs as a result of a failed 673 ACL STORE or ACL SET command. The first two strings are 674 the mailbox name and identifier for which this rights list 675 applies. Following the identifier is a string containing 676 the (possibly empty) set of rights the identifier will always 677 be granted in the mailbox. 679 Following this are zero or more strings each containing a set of 680 rights the identifier may be granted in the mailbox. Rights 681 mentioned in the same string are tied together--either all must be 682 granted to the identifier in the mailbox or none may be granted. 684 The same right may not be listed more than once in the RIGHTS-INFO 685 response. 687 5.3. ACLFAILED untagged response 689 Contents: mailbox name 690 OPTIONAL response code and human readable text for failure 691 reason 693 The ACLFAILED response containing a mailbox name indicates that 694 the ACL operations failed for the specified mailbox. The reason for 695 failure may be described by the response code (if included). If 696 the command for the mailbox fails because some rights are tied, 697 the server MUST return RIGHTS-INFO response instead of ACLFAILED. 699 Example: C: A002 ACL SET (INBOX Personal/*) user=Fred rwist 700 S: * ACLFAILED Personal/ABC 701 S: A002 OK acl set complete 703 5.4. Extended LIST response with MYRIGHTS information 705 Contents: name attributes 706 hierarchy delimiter 707 mailbox name 708 MYRIGHTS information (list of rights) 710 This version of LIST response occurs as a result of a LIST (MYRIGHTS) 711 command. The proposed syntax conforms to the syntax of an extended 712 LIST response as defined by mbox-list-extended ABNF element of [LISTEXT]. 714 The meaning of "name attributes" and "hierarchy delimiter" is described in 715 section 7.2.2 of [IMAP4]. This is followed by the extension part that 716 includes "MYRIGHTS" tag followed by the set of rights that the user has. 718 <> 720 Example: S: * LIST () "/" Sent (("MYRIGHTS" "lrwiste")) 722 5.5. MYRIGHTS response code 724 Data: rights 726 The MYRIGHTS response code is sent in an untagged OK response 727 that results from SELECT/EXAMINE. Also this response code can be 728 sent at any time after opening a mailbox when the server detects 729 that the set of rights allowed for the logged in user has changed. 731 The MYRIGHTS response code is equivalent to the MYRIGHTS data returned 732 in an untagged LIST response for the selected mailbox. 734 6. Formal Syntax 736 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 737 Non-terminals referenced but not defined below are as defined by 738 [IMAP4] or [LISTEXT]. 740 Except as noted otherwise, all alphabetic characters are 741 case-insensitive. The use of upper or lower case characters to 742 define token strings is for editorial clarity only. Implementations 743 MUST accept these strings in a case-insensitive fashion. 745 acl2_command = "ACL" SP acl2_subcommand | list 747 acl2_subcommand = replaceacl | deleteacl | updateacl 749 acl_list_data = "(" acl_list_tag SP acl_data ")" 750 ;; acl_list_data conforms to the syntax of 751 ;; mbox-list-extended-item from [LISTEXT] 753 acl_list_tag = <"> "ACL" <"> 755 ace = "(" identifier SP rights ")" 757 acl_data = "NIL" | acl_data_nonemp 758 ;; NIL, or one or more parenthesized identifier/rights pairs 760 acl_data_nonemp = "(" ace *( SP ace ) ")" 762 always_granted = rights 764 deleteacl = "DELETE" SP mbox_or_pat SP identifier 766 option =/ "ACL" | "MYRIGHTS" 767 ;;