idnits 2.17.1 draft-ietf-imapext-2086upd-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 783. -- Found old boilerplate from RFC 3978, Section 5.5 on line 819. ** 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 978 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 142 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2004) is 7065 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'StringPrep' is mentioned on line 208, but not defined == Missing Reference: 'UNSEEN 12' is mentioned on line 575, but not defined == Missing Reference: 'UIDVALIDITY 3857529045' is mentioned on line 576, but not defined == Missing Reference: 'UIDNEXT 4392' is mentioned on line 577, but not defined == Unused Reference: 'Stringprep' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'RFC2086' is defined on line 768, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 3454 (ref. 'Stringprep') (Obsoleted by RFC 7564) -- No information found for draft-ietf-sasl-saslprep-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASLprep' -- Obsolete informational reference (is this intentional?): RFC 2086 (Obsoleted by RFC 4314) Summary: 16 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAPEXT Working Group A. Melnikov 2 Internet Draft Editor 3 Document: draft-ietf-imapext-2086upd-02.txt December 2004 4 Updates: <<3501?>> 5 Obsoletes: 2086 6 Expires: June 2005 8 IMAP4 ACL extension 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, or 14 will be disclosed, and any of which I become aware will be disclosed, 15 in accordance with RFC 3668. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its Areas, and its Working Groups. Note that 19 other groups may also distribute working documents as Internet 20 Drafts. Internet Drafts are draft documents valid for a maximum of 21 six months. Internet Drafts may be updated, replaced, or obsoleted 22 by other documents at any time. It is not appropriate to use 23 Internet Drafts as reference material or to cite them other than as 24 ``work in progress''. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 33 munnari.oz.au. 35 A revised version of this draft document will be submitted to the RFC 36 editor as a Proposed Standard for the Internet Community. Discussion 37 and suggestions for improvement are requested. Distribution of this 38 draft is unlimited. 40 Abstract 42 The ACL (Access Control List) extension (RFC 2086) of the Internet 43 Message Access Protocol (IMAP4rev1) permits mailbox access control 44 lists to be manipulated through the IMAP protocol. 46 This document is a revision of the RFC 2086. It defines several new 47 access control rights and clarifies which rights are required for 48 different IMAP commands. 50 1. Conventions Used in this Document 52 In examples, "C:" and "S:" indicate lines sent by the client and 53 server respectively. 55 In all examples "/" character is used as hierarchy separator. 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 61 2. Introduction and Overview 63 The ACL (Access Control List) extension of the Internet Message Access 64 Protocol [IMAP4] permits mailbox access control lists to be retrieved 65 and manipulated through the IMAP protocol. 67 This document is a revision of the RFC 2086. It tries to clarify 68 different ambiguities in the RFC 2086, in particular use of UTF-8 69 [UTF-8] in identifiers, which rights are required for different IMAP4 70 commands; how READ-WRITE/READ-ONLY response codes are related to ACL. 72 3. Access Control 74 The ACL extension is present in any IMAP4 implementation which 75 returns "ACL" as one of the supported capabilities to the CAPABILITY 76 command. 78 A server implementation conformant to this document MUST also return 79 rights (see below) not defined in RFC 2086 in the "RIGHTS=" capability 80 response. 82 An access control list is a set of pairs. 83 An ACL applies to a mailbox name. 85 Identifier is a UTF-8 [UTF-8] string. The identifier "anyone" is reserved 86 to refer to the universal identity (all authentications, including 87 anonymous). All user name strings accepted by the LOGIN or 88 AUTHENTICATE commands to authenticate to the IMAP server are reserved 89 as identifiers for the corresponding users. Identifiers starting with 90 a dash ("-") are reserved for "negative rights", described below. 91 All other identifier strings are interpreted in an implementation- 92 defined manner. 94 Rights is a string listing a (possibly empty) set of alphanumeric 95 characters, each character listing a set of operations which is being 96 controlled. Lowercase letters are reserved for "standard" rights, 97 listed in section 3.1. (Note that for compatibility with deployed clients 98 and servers uppercase rights are not allowed). The set of 99 standard rights may only be extended by a standards-track document. 100 Digits are reserved for implementation or site defined rights. 102 An implementation may tie rights together or may force rights to 103 always or never be granted to particular identifiers. For example, 104 in an implementation that uses unix mode bits, the rights "swite" are 105 tied, the "a" right is always granted to the owner of a mailbox and 106 is never granted to another user. If rights are tied in an 107 implementation, the implementation must be conservative in granting 108 rights in response to SETACL commands--unless all rights in a tied 109 set are specified, none of that set should be included in the ACL 110 entry for that identifier. A client may discover the set of rights 111 which may be granted to a given identifier in the ACL for a given 112 mailbox name by using the LISTRIGHTS command. 114 It is possible for multiple identifiers in an access control list to 115 apply to a given user (or other authentication identity). For 116 example, an ACL may include rights to be granted to the identifier 117 matching the user, one or more implementation-defined identifiers 118 matching groups which include the user, and/or the identifier 119 "anyone". How these rights are combined to determine the user's 120 access is implementation-defined. An implementation may choose, for 121 example, to use the union of the rights granted to the applicable 122 identifiers. An implementation may instead choose, for example, to 123 only use those rights granted to the most specific identifier present 124 in the ACL. A client may determine the set of rights granted to the 125 logged-in user for a given mailbox name by using the MYRIGHTS command. 127 When an identifier in an ACL starts with a dash ("-"), that indicates 128 that associated rights are to be removed from the identifier that is 129 prefixed by the dash. This is referred to as a "negative right". 130 This differs from DELETEACL in that a negative right is added to the 131 ACL, and is a part of the calculation of the rights. 133 Let's assume that an identifier "fred" refers to a user with login "fred". 134 If the identifier "-fred" is granted the "w" right, 135 that indicates that the "w" right is to be removed from users matching 136 the identifier "fred", even though the user "fred" might have 137 the "w" right as a consequence of some other identifier in the ACL. 138 A DELETEACL of "fred" simply deletes the identifier "fred" 139 from the ACL; it does not affect any rights that the user "fred" 140 may get from another entry in the ACL. 142 Server implementations are not required to support "negative right" 143 identifiers. 145 3.1. Standard rights 147 The currently defined standard rights are (note, that the list below 148 doesn't list all commands that use a particular right): 150 l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE mailbox) 151 r - read (SELECT the mailbox, perform STATUS) 152 s - keep seen/unseen information across sessions (set or clear \SEEN flag 153 via STORE, APPEND or COPY) 154 w - write (set or clear flags other than \SEEN and \DELETED via STORE, 155 APPEND or COPY) 156 i - insert (perform APPEND, COPY into mailbox) 157 p - post (send mail to submission address for mailbox, 158 not enforced by IMAP4 itself) 159 k - create mailboxes (CREATE new sub-mailboxes in any 160 implementation-defined hierarchy, parent mailbox for the new 161 mailbox name in RENAME) 162 x - delete mailbox (DELETE mailbox, old mailbox name in RENAME) 163 t - delete messages (set or clear \DELETED flag via STORE, set \DELETED flag 164 during APPEND/COPY) 165 e - perform EXPUNGE and expunge as a part of CLOSE. 166 a - administer (perform SETACL/DELETEACL/GETACL) 168 3.1.1. Obsolete rights 170 Due to ambiguity in RFC 2086 some existing RFC 2086 server implementations 171 use the "c" right to control the DELETE command. Others chose to use the 172 "d" right to control the DELETE command. 173 For the former group, let's define the "create" right as union of the "k" 174 and "x" rights, and the "delete" right as union of the "e" and "t" rights. 175 For the latter group, let's define the "create" rights as a synonym to the 176 "k" right, and the "delete" right as union of the "e", "t" and "x" rights. 178 For compatibility with RFC 2086 this section defines two virtual rights 179 "d" and "c". 181 If a client includes the "d" right in a rights list, then it MUST be 182 treated as if the client had included every member of the "delete" right. 183 (It is not an error for a client to specify both the "d" right and 184 one or more member of the "delete" right, but the effect is no different 185 than if just the "d" right or all members of the "delete" right had been 186 specified). When all the "delete" member rights are set in a list of 187 rights, the server MUST also include the "d" right when returning 188 the list in a MYRIGHTS or ACL response. 189 If member of the "delete" right are not tied together, the "d" right 190 MUST NOT be returned in a LISTRIGHTS response. 192 If a client includes the "c" right in a rights list, then it MUST be 193 treated as if the client had included every member of the "create" right. 194 (It is not an error for a client to specify both the "c" right and 195 one or more member of the "create" right, but the effect is no different 196 than if just the "c" right or all members of the "create" right had been 197 specified). When all the "create" member rights are set in a list of 198 rights, the server MUST also include the "c" right when returning 199 the list in a MYRIGHTS or ACL response. 200 If member of the "create" right are not tied together, the "c" right 201 MUST NOT be returned in a LISTRIGHTS response. 203 4. Access control management commands and responses 205 Servers, when processing a command that have an authentication identifier 206 as a parameter (i.e. any of SETACL, DELETEACL and LISTRIGHTS commands), 207 SHOULD first prepare the received identifier using "SASLprep" profile 208 [SASLprep] of the "stringprep" algorithm [StringPrep]. If the 209 preparation of the identifier fails or results in an empty string, the 210 server MUST refuse to perform the command with a BAD response. 212 4.1. SETACL command 214 Arguments: mailbox name 215 authentication identifier 216 access right modification 218 Data: no specific data for this command 220 Result: OK - setacl completed 221 NO - setacl failure: can't set acl 222 BAD - arguments invalid 224 The SETACL command changes the access control list on the 225 specified mailbox so that the specified identifier is granted 226 permissions as specified in the third argument. 228 The third argument is a string containing an optional plus ("+") 229 or minus ("-") prefix, followed by zero or more rights characters. 230 If the string starts with a plus, the following rights are added 231 to any existing rights for the identifier. If the string starts 232 with a minus, the following rights are removed from any existing 233 rights for the identifier. If the string does not start with a 234 plus or minus, the rights replace any existing rights for the 235 identifier. 237 Note, that an unrecognized right MUST cause the command to return 238 the BAD response. In particular, server MUST NOT silently ignore 239 unrecognized rights. 241 Example: C: A001 SETACL INBOX.Drafts Chris lrswicda 242 S: A001 OK Setacl complete 244 C: A035 SETACL INBOX.Drafts John lrQswicda 245 S: A035 BAD Uppercase rights are not allowed 247 C: A036 SETACL INBOX.Drafts John lrqswicda 248 S: A036 BAD The q right is not supported 250 4.2. DELETEACL command 252 Arguments: mailbox name 253 authentication identifier 255 Data: no specific data for this command 257 Result: OK - deleteacl completed 258 NO - deleteacl failure: can't delete acl 259 BAD - arguments invalid 261 The DELETEACL command removes any pair for the 262 specified identifier from the access control list for the specified 263 mailbox. 265 4.3. GETACL command 267 Arguments: mailbox name 269 Data: untagged responses: ACL 271 Result: OK - getacl completed 272 NO - getacl failure: can't get acl 273 BAD - arguments invalid 275 The GETACL command returns the access control list for mailbox in 276 an untagged ACL response. 278 Some implementations may permit multiple forms of an authentication 279 identifier to reference the same IMAP account. Usually, such 280 implementations will have a canonical form that is stored internally. 281 An ACL response caused by an GETACL command may include a 282 canonicalized form of the authentication identifier which might be 283 different from the one used in the corresponding SETACL command. 285 Example: C: A002 GETACL INBOX 286 S: * ACL INBOX Fred rwipslda 287 S: A002 OK Getacl complete 289 4.4. LISTRIGHTS command 291 Arguments: mailbox name 292 authentication identifier 294 Data: untagged responses: LISTRIGHTS 296 Result: OK - listrights completed 297 NO - listrights failure: can't get rights list 298 BAD - arguments invalid 300 The LISTRIGHTS command takes a mailbox name and an identifier and 301 returns information about what rights may be granted to the identifier 302 in the ACL for the mailbox. 304 Some implementations may permit multiple forms of an authentication 305 identifier to reference the same IMAP account. Usually, such 306 implementations will have a canonical form that is stored internally. 307 A LISTRIGHTS response caused by a LISTRIGHTS command MUST always 308 return the same form of an authentication identifier as specified 309 by the client. This is to allow the client to correlate the response 310 with the command. 312 Example: C: a001 LISTRIGHTS ~/Mail/saved smith 313 S: * LISTRIGHTS ~/Mail/saved smith la r swicd 314 S: a001 OK Listrights completed 316 C: a005 LISTRIGHTS archive.imap anyone 317 S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a 318 0 1 2 3 4 5 6 7 8 9 319 S: a005 Listrights successful 321 4.5. MYRIGHTS command 323 Arguments: mailbox name 325 Data: untagged responses: MYRIGHTS 327 Result: OK - myrights completed 328 NO - myrights failure: can't get rights 329 BAD - arguments invalid 331 The MYRIGHTS command returns the set of rights that the user has 332 to mailbox in an untagged MYRIGHTS reply. 334 Example: C: A003 MYRIGHTS INBOX 335 S: * MYRIGHTS INBOX rwipslda 336 S: A003 OK Myrights complete 338 4.6. ACL response 340 Data: mailbox name 341 zero or more identifier rights pairs 343 The ACL response occurs as a result of a GETACL command. The first 344 string is the mailbox name for which this ACL applies. This is 345 followed by zero or more pairs of strings, each pair contains the 346 identifier for which the entry applies followed by the set of 347 rights that the identifier has. 349 4.7. LISTRIGHTS response 351 Data: mailbox name 352 identifier 353 required rights 354 list of optional rights 356 The LISTRIGHTS response occurs as a result of a LISTRIGHTS 357 command. The first two strings are the mailbox name and identifier 358 for which this rights list applies. Following the identifier is a 359 string containing the (possibly empty) set of rights the 360 identifier will always be granted in the mailbox. 362 Following this are zero or more strings each containing a set of 363 rights the identifier may be granted in the mailbox. Rights 364 mentioned in the same string are tied together--either all must be 365 granted to the identifier in the mailbox or none may be granted. 367 The same right may not be listed more than once in the LISTRIGHTS 368 command. 370 4.8. MYRIGHTS response 372 Data: mailbox name 373 rights 375 The MYRIGHTS response occurs as a result of a MYRIGHTS command. 376 The first string is the mailbox name for which these rights apply. 377 The second string is the set of rights that the client has. 379 5. Rights required to perform different IMAP4rev1 commands 381 Before executing a command an ACL compliant server must check which rights 382 are required to perform it. This section groups command by functions 383 they perform and list the rights required. It also gives the detailed 384 description of any special processing required. 386 For the purpose of this section the UID counterpart of a command is 387 considered to be the same command, e.g. both UID COPY and COPY commands 388 require the same set of rights. 390 The table below summarizes different rights or their combinations that are 391 required in order to perform different IMAP operations. As it is not always 392 possible to express complex right checking and interactions, the description 393 after the table should be used as the primary reference. 395 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 396 | Operations\Rights | l | r | s | w | i | k | x | t | e | a | Any | None | 397 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 398 | LIST | + | | | | | | | | | | | | 399 | SUBSCRIBE | * | | | | | | | | | | | * | 400 | UNSUBSCRIBE | | | | | | | | | | | | + | 401 | LSUB | * | | | | | | | | | | | * | 402 | CREATE (for parent) | | | | | | + | | | | | | | 403 | DELETE | | | | | | | + | ? | ? | | | | 404 | RENAME | | | | | | + | + | | | | | | 405 | COPY/APPEND | | | ? | ? | + | | | ? | | | | | 406 | EXPUNGE/CLOSE | | | | | | | | | + | | | | 407 |SELECT/EXAMINE/STATUS| | + | | | | | | | | | | | 408 | FETCH | | | ? | | | | | | | | | | 409 | STORE flags | | | ? | ? | | | | ? | | | | | 410 | SETACL/DELETEACL | | | | | | | | | | + | | | 411 | GETACL/LISTRIGHTS | | | | | | | | | | + | | | 412 | MYRIGHTS | | | | | | | | | | | + | | 413 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 415 Legend: 416 + - The right is required 417 * - Only one of the rights marked with * is required (see description below) 418 ? - The right is optional (see description below) 419 "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is 420 required 421 "None" - No rights required to perform the command 423 Listing and subscribing/unsubscribing mailboxes: 424 LIST - "l" right is required. 426 Note, that if the user has "l" right to a mailbox "A/B", but not to its parent 427 mailbox "A", the LIST command should behave as if the mailbox "A" doesn't exist, 428 for example: 429 C: A777 LIST "" * 430 S: * LIST (\NoInferiors) "/" "A/B" 431 S: * LIST () "/" "C" 432 S: * LIST (\NoInferiors) "/" "C/D" 433 S: A777 OK LIST completed 435 SUBSCRIBE - "l" right is required only if the server checks for mailbox existence 436 when performing SUBSCRIBE. 438 UNSUBSCRIBE - no rights required to perform this operation. 440 LSUB - "l" right is required only if the server checks for mailbox existence when 441 performing SUBSCRIBE. 443 Mailbox management: 444 CREATE - "k" right on a nearest existing parent mailbox. When a new 445 mailbox is created it SHOULD inherit the ACL from the parent 446 mailbox (if one exists) in the defined hierarchy. 448 DELETE - "x" right on the mailbox. Note, that some servers don't allow 449 to delete a non-empty mailbox. If this is the case, the user 450 also need both "e" and "t" rights, in order to make the mailbox 451 empty first. 453 The DELETE command MUST delete the ACL associated with the 454 deleted mailbox. 456 RENAME - Moving a mailbox from one parent to another requires the "x" right 457 on the mailbox itself and the "k" right for the new parent. 458 For example, if the user wants to rename mailbox named "A/B/C" to 459 "D/E", the user must have the "x" right for the mailbox "A/B/C" 460 and the "k" right for the mailbox "D". 462 The RENAME command SHOULD NOT change the ACLs on the renamed 463 mailbox and submailboxes. 465 Copying or appending messages: 467 Before performing a COPY/APPEND command the server MUST check if the 468 user has "i" right for the target mailbox. If the user doesn't have "i" 469 right, the operation fails. Otherwise for each copied/appended message 470 the server MUST check if the user has 471 "t" right - when the message has \Deleted flag set 472 "s" right - when the message has \Seen flag set 473 "w" right for all other message flags. 474 Only when the user has a particular right the corresponding flags are 475 stored for the newly created message. The server MUST NOT fail 476 a COPY/APPEND if the user has no rights to set a particular flag. 478 Example: C: A003 MYRIGHTS TargetMailbox 479 S: * MYRIGHTS TargetMailbox rwis 480 S: A003 OK Myrights complete 482 C: A004 FETCH 1:3 (FLAGS) 483 S: * 1 FETCH (FLAGS (\Draft \Deleted) 484 S: * 2 FETCH (FLAGS (\Answered) 485 S: * 3 FETCH (FLAGS ($Forwarded \Seen) 486 S: A004 OK Fetch Completed 488 C: A005 COPY 1:3 TargetMailbox 489 S: A005 OK Copy completed 491 C: A006 SELECT TargetMailbox 492 ... 493 S: A006 Select Completed 495 Let's assume that the copied messages received message numbers 77:79. 497 C: A007 FETCH 77:79 (FLAGS) 498 S: * 77 FETCH (FLAGS (\Draft)) 499 S: * 78 FETCH (FLAGS (\Answered)) 500 S: * 79 FETCH (FLAGS ($Forwarded \Seen)) 501 S: A007 OK Fetch Completed 503 \Deleted flag was lost on COPY, as the user has no "t" right in the 504 target mailbox. 506 If the MYRIGHTS command with the tag A003 would have returned: 507 S: * MYRIGHTS TargetMailbox rsti 509 the response from the FETCH with the tag A007 would have been: 511 C: A007 FETCH 77:79 (FLAGS) 512 S: * 77 FETCH (FLAGS (\Deleted)) 513 S: * 78 FETCH (FLAGS ()) 514 S: * 79 FETCH (FLAGS (\Seen)) 515 S: A007 OK Fetch Completed 517 In the latter case \Answered, $Forwarded and \Draft flags were lost 518 on COPY, as the user has no "w" right in the target mailbox. 520 Expunging the selected mailbox: 521 EXPUNGE - "e" right on the selected mailbox. 523 CLOSE - "e" right on the selected mailbox. If the server is unable to 524 expunge the mailbox because the user doesn't have the "e" right, 525 the server MUST ignore expunge request, close the mailbox 526 and return tagged OK response. 528 Fetch information about a mailbox and its messages: 529 SELECT/EXAMINE/STATUS - "r" right on the mailbox. 531 FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it, 532 if the current user doesn't have "s" right. 534 Changing flags: 535 STORE - the server MUST check if the user has 536 "t" right - when the user modifies \Deleted flag 537 "s" right - when the user modifies \Seen flag 538 "w" right for all other message flags. 539 STORE operation SHOULD NOT fail if the user has rights to modify at least 540 one flag specified in the STORE, as the tagged NO response to a STORE 541 command is not handled very well by deployed clients. 543 Changing ACLs: 544 SETACL/DELETEACL - "a" right on the mailbox. 546 Reading ACLs: 547 GETACL - "a" right on the mailbox. 549 MYRIGHTS - any of the following rights is required to perform 550 the operation: "l", "r", "i", "k", "x", "a". 552 LISTRIGHTS - "a" right on the mailbox. 554 6. Other considerations 556 6.1. Additional requirements and Implementation notes 558 6.1.1. Servers 560 This document defines an additional capability that is used to announce 561 the list of extra rights (excluding the ones defined in the RFC 2086) 562 supported by the server. The set of rights MUST include "t", "e", "x" and "k". 563 Note, that the extra rights can appear in any order. 565 Example: C: 1 capability 566 S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ ACL RIGHTS=texk 567 S: 1 OK completed 569 Any server implementing an ACL extension MUST accurately reflect the current 570 user's rights in FLAGS and PERMANENTFLAGS responses. 572 Example: C: A142 SELECT INBOX 573 S: * 172 EXISTS 574 S: * 1 RECENT 575 S: * OK [UNSEEN 12] Message 12 is first unseen 576 S: * OK [UIDVALIDITY 3857529045] UIDs valid 577 S: * OK [UIDNEXT 4392] Predicted next UID 578 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 579 S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] Limited 580 S: A142 OK [READ-WRITE] SELECT completed 581 C: A143 MYRIGHTS INBOX 582 S: * MYRIGHTS INBOX rwis 583 S: A143 OK completed 585 Servers MAY cache the rights a user has on a mailbox when the mailbox 586 is selected, so that if a client's rights on a mailbox are changed with 587 SETACL or DELETEACL, commands specific to the selected state (e.g., STORE, 588 EXPUNGE) might not reflect the changed rights until the mailbox is 589 re-selected. If the server checks the rights on each command, then it SHOULD 590 send FLAGS and PERMANENTFLAGS responses if they have changed. 592 An ACL server MAY modify one or more ACL for one or more identifier as a 593 side effect of modifying the ACL specified in a SETACL/DELETEACL. 594 If the server does that it MUST send untagged ACL response to notify the 595 client about the changes made. 597 6.1.2. Clients 599 A client implementation that allows a user to read and update ACLs MUST 600 preserve unrecognized rights that it doesn't allow the user to change 601 when updating the rights. Otherwise the client may unintentionally remove 602 permissions. 604 6.2. Mapping of ACL rights to READ-WRITE and READ-ONLY response codes 606 A particular ACL server implementation may allow "shared multiuser 607 access" to some mailboxes. "Shared multiuser access" to a mailbox means 608 that multiple different users are able to access the same mailbox, 609 if they have proper access rights. "Shared multiuser access" to the 610 mailbox doesn't mean that the ACL for the mailbox is currently set 611 to allow access by multiple users. Let's denote a "shared multiuser 612 write access" as a "shared multiuser access" when a user may be 613 granted flag modification rights (any of "w", "s" or "t"). 615 Section 5 describes which rights are required for modifying different flags. 617 If the ACL server implements some flags as shared for a mailbox (i.e., 618 the ACL for the mailbox may be set up so that changes to those flags are 619 visible to another user), let's call the set of rights associated with these 620 flags (as described in Section 5) for that mailbox collectively as 621 "shared flag rights". Note, that "shared flag rights" set MAY be different 622 for different mailboxes. 624 If the server doesn't support "shared multiuser write access" to a 625 mailbox or doesn't implement shared flags on the mailbox, "shared flag 626 rights" for the mailbox is defined to be the empty set. 628 Example 1: Mailbox "banan" allows "shared multiuser write access" and 629 implements flags \Deleted, \Answered and $MDNSent as 630 shared flags. "Shared flag rights" for the mailbox "banan" 631 is a set containing flags "t" (because system flag \Deleted 632 requires "t" right) and "w" (because both \Answered and 633 $MDNSent require "w" right). 635 Example 2: Mailbox "apple" allows "shared multiuser write access" and 636 implements \Seen system flag as shared flag. "Shared flag 637 rights" for the mailbox "apple" contains "s" right, 638 because system flag \Seen requires "s" right. 640 Example 3: Mailbox "pear" allows "shared multiuser write access" and 641 implements flags \Seen, \Draft as shared flags. "Shared flag 642 rights" for the mailbox "apple" is a set containing flags "s" 643 (because system flag \Seen requires "s" right) and "w" 644 (because system flag \Draft requires "w" right). 646 The server MUST include a READ-ONLY response code in the tagged OK response to 647 a SELECT command if none of the following rights is granted to the 648 current user: 649 "i", "e" and "shared flag rights"*. 650 The server SHOULD include a READ-WRITE response code in the tagged OK response 651 if at least one of the "i", "e" or "shared flag rights"* is granted to the 652 current user. 654 * - Note that a future extension to this document may extend the list of 655 rights that causes the server to return the READ-WRITE response code. 657 Example 1 (continued): The user that has "lrs" rights for the mailbox 658 "banan". The server returns READ-ONLY response 659 code on SELECT, as none of "iewt" rights is 660 granted to the user. 662 Example 2 (continued): The user that has "rit" rights for the mailbox 663 "apple". The server returns READ-WRITE response 664 code on SELECT, as the user has "i" right. 666 Example 3 (continued): The user that has "rset" rights for the mailbox 667 "pear". The server returns READ-WRITE response 668 code on SELECT, as the user has "e" and "s" rights. 670 7. Security Considerations 672 An implementation must make sure the ACL commands themselves do not 673 give information about mailboxes with appropriately restricted ACL's. 674 For example, a GETACL command on a mailbox for which the user has 675 insufficient rights should not admit that the mailbox exists, much less 676 return the mailbox's ACL. 678 LISTRIGHTS command MUST NOT check that a particular identifier exists, 679 however it SHOULD recognize special identifiers like "anyone". 681 IMAP clients implementing ACL that are able to modify ACLs SHOULD 682 warn a user that wants to give full access (or even just the "a" right) 683 to the special identifier "anyone". 685 8. Formal Syntax 687 Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. 688 Non-terminals referenced but not defined below are as defined by 689 [IMAP4]. 691 Except as noted otherwise, all alphabetic characters are 692 case-insensitive. The use of upper or lower case characters to 693 define token strings is for editorial clarity only. Implementations 694 MUST accept these strings in a case-insensitive fashion. 696 LOWER_ALPHA = %x61-7A ;; a-z 698 acl_data = "ACL" SP mailbox *(SP identifier SP 699 rights) 701 deleteacl = "DELETEACL" SP mailbox SP identifier 703 getacl = "GETACL" SP mailbox 705 identifier = astring 707 listrights = "LISTRIGHTS" SP mailbox SP identifier 709 listrights_data = "LISTRIGHTS" SP mailbox SP identifier 710 SP rights *(SP rights) 712 mod_rights = astring 713 ;; +rights to add, -rights to remove 714 ;; rights to replace 716 myrights = "MYRIGHTS" SP mailbox 718 myrights_data = "MYRIGHTS" SP mailbox SP rights 720 new_rights = 1*(LOWER_ALPHA / DIGIT) 721 ;; MUST include "t", "e", "x" and "k" 723 rights = astring 724 ;; only lowercase ASCII letters and digits 725 ;; are allowed. 727 rights_capa = "RIGHTS=" new_rights 728 ;; RIGHTS=... capability 729 setacl = "SETACL" SP mailbox SP identifier 730 SP mod_rights 732 9. IANA Considerations 734 IMAP4 capabilities are registered by publishing a standards track or 735 IESG approved experimental RFC. The registry is currently located 736 at: 738 http://www.iana.org/assignments/imap4-capabilities 740 This document defines the RIGHTS= IMAP capability. IANA is requested 741 to add this capability to the registry. 743 10. References 745 10.1. Normative References 747 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 748 Requirement Levels", RFC 2119, Harvard University, March 1997. 750 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 751 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 752 November 1997. 754 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 755 4rev1", RFC 3501, University of Washington, March 2003. 757 [UTF-8] Yergeau, F., "UTF-8, a transformation format of IS0 10646", 758 RFC 3629, Alis Technologies, November 2003. 760 [Stringprep] Hoffman, P., Blanchet, M., "Preparation of 761 Internationalized Strings ("stringprep")", RFC 3454, December 2002. 763 [SASLprep] Zeilenga, K., "SASLprep: Stringprep profile for user names 764 and passwords", Work in progress, draft-ietf-sasl-saslprep-XX.txt. 766 10.2. Informative References 768 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, Carnegie Mellon, 769 January 1997. 771 11. Editor's Address 773 Alexey Melnikov 774 email: alexey.melnikov@isode.com 776 Isode Limited 778 12. IPR Disclosure Acknowledgement 780 By submitting this Internet-Draft, I certify that any applicable 781 patent or other IPR claims of which I am aware have been disclosed, 782 and any of which I become aware will be disclosed, in accordance with 783 RFC 3668. 785 13. Intellectual Property Statement 787 The IETF takes no position regarding the validity or scope of any 788 intellectual property or other rights that might be claimed to 789 pertain to the implementation or use of the technology described in 790 this document or the extent to which any license under such rights 791 might or might not be available; neither does it represent that it 792 has made any effort to identify any such rights. Information on the 793 IETF's procedures with respect to rights in standards-track and 794 standards-related documentation can be found in BCP-11. Copies of 795 claims of rights made available for publication and any assurances of 796 licenses to be made available, or the result of an attempt made to 797 obtain a general license or permission for the use of such 798 proprietary rights by implementors or users of this specification can 799 be obtained from the IETF Secretariat. 801 The IETF invites any interested party to bring to its attention any 802 copyrights, patents or patent applications, or other proprietary 803 rights which may cover technology that may be required to practice 804 this standard. Please address the information to the IETF Executive 805 Director. 807 14. Full Copyright Statement 809 Copyright (C) The Internet Society (2004). This document is subject 810 to the rights, licenses and restrictions contained in BCP 78 and 811 except as set forth therein, the authors retain all their rights. 813 This document and the information contained herein are provided on an 814 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 815 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 816 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 817 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 818 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 819 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 821 Acknowledgement 823 Funding for the RFC Editor function is currently provided by the 824 Internet Society. 826 Appendix A. Changes since RFC 2086 828 1. Changed the charset of "identifier" from US-ASCII to UTF-8. 830 2. Specified that mailbox deletion is controled by the "x" right and 831 EXPUNGE is controlled by the "e" right. 833 3. Added the "t" right that controls STORE \Deleted. Redefined the "d" 834 right to be a macro for "e", "t" and possibly "x". 836 4. Added the "k" right that controls CREATE. Redefined the "c" 837 right to be a macro for "k" and possibly "x". 839 5. Specified that the "a" right also controls DELETEACL. 841 6. Specified that the "r" right also controls STATUS. 843 7. Removed the requirement to check the "r" right for CHECK, SEARCH and 844 FETCH, as this is required for SELECT/EXAMINE to be successful. 846 8. LISTRIGHTS requires the "a" right on the mailbox (same as SETACL). 848 9. Deleted "PARTIAL", this is a deprecated feature of RFC 1730. 850 10. Specified that the "w" right controls setting flags other than \Seen 851 and \Deleted on APPEND. Also specified that the "s" right controls 852 the \Seen flag and that the "t" right controls the \Deleted flag. 854 11. SUBSCRIBE is NOT allowed with the "r" right. 856 12. Specified that the "l" right controls SUBSCRIBE. 858 13. GETACL is NOT allowed with the "r" right, even though there are 859 several implementations that allows that. If a user only has "r" 860 right, GETACL can disclose information about identifiers existing 861 on the mail system. 863 14. Clarified that RENAME requires the "k" right for the new parent and 864 the "x" right for the old name. 866 15. Added new section that describes which rights are required and/or 867 checked when performing various IMAP commands. 869 16. Added mail client security considerations when dealing with special 870 identifier "anyone". 872 17. Clarified that negative rights are not the same as DELETEACL. 874 18. Added "Compatibility with RFC 2086" section. 876 19. Added section about mapping of ACL rights to READ-WRITE and READ-ONLY 877 response codes. 879 20. Changed BNF to ABNF. 881 21. Added "Implementation Notes" section. 883 22. Updated "References" section. 885 Appendix B. Compatibility with RFC 2086 887 This section gives guidelines how an existing RFC 2086 server 888 implementation may be updated to comply with this document. 890 This document splits the "d" right into several new different rights: "t", 891 "e" and possibly "x" (see section 3.1.1 for more details). The "d" right 892 remains for backwards-compatibility but it is a virtual right. The server 893 should implement one of the following two approaches to handle the "d" right 894 and the new rights that have replaced it. 896 a). "t", "e" (and possibly "x) together - almost no changes. 897 b). Implement separate "x", "t" and "e". Return the "d" right in a 898 MYRIGHTS response or an ACL response containing ACL 899 information when all of the "t", "e" (and "x") are granted. 901 In a similar manner this document splits the "c" right into several new 902 different rights: "k" and possibly "x" (see section 3.1.1 for more details). 903 The "c" right remains for backwards-compatibility but it is a virtual right. 904 The server should implement one of the two approaches described above. 906 Also check Sections 6.1 and 6.2, as well as the appendix A to see 907 other changes required. Server implementors should check which rights 908 are required to invoke different IMAP4 commands as described in 909 Section 5. 911 Appendix C. Known deficiencies 913 This specification has some known deficiencies including: 915 1. This is inadequate to provide complete read-write access to mailboxes 916 protected by Unix-style rights bits because there is no equivalent to 917 "chown" and "chgrp" commands nor is there a good way to discover such 918 limitations are present. 920 2. Because this extension leaves the specific semantics of how rights are 921 combined by the server and which rights are tied as implementation 922 defined, the ability to build a user-friendly interface is limited. 924 The work-in-progress "ACL2" extension is intended to redesign this 925 extension to address these deficiencies without the constraint of 926 backwards-compatibility and may eventually supercede this facility. 927 However, RFC 2086 is deployed in multiple implementations so this 928 intermediate step which fixes the straightforward deficiencies in a 929 backwards compatible fashion is considered worthwhile. 931 Appendix D. Acknowledgment 933 This document is a revision of the RFC 2086 written by John G. Myers. 935 Editor appreciates comments received from Mark Crispin, Chris Newman, 936 Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole, 937 Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie 938 Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon 939 Nerenberg and other participants of the IMAPEXT working group.