imapext-2007

annotate docs/rfc/rfc4314.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group A. Melnikov
yuuji@0 8 Request for Comments: 4314 Isode Ltd.
yuuji@0 9 Obsoletes: 2086 December 2005
yuuji@0 10 Category: Standards Track
yuuji@0 11
yuuji@0 12
yuuji@0 13 IMAP4 Access Control List (ACL) Extension
yuuji@0 14
yuuji@0 15 Status of this Memo
yuuji@0 16
yuuji@0 17 This document specifies an Internet standards track protocol for the
yuuji@0 18 Internet community, and requests discussion and suggestions for
yuuji@0 19 improvements. Please refer to the current edition of the "Internet
yuuji@0 20 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 21 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 22
yuuji@0 23 Copyright Notice
yuuji@0 24
yuuji@0 25 Copyright (C) The Internet Society (2005).
yuuji@0 26
yuuji@0 27 Abstract
yuuji@0 28
yuuji@0 29 The Access Control List (ACL) extension (RFC 2086) of the Internet
yuuji@0 30 Message Access Protocol (IMAP) permits mailbox access control lists
yuuji@0 31 to be retrieved and manipulated through the IMAP protocol.
yuuji@0 32
yuuji@0 33 This document is a revision of RFC 2086. It defines several new
yuuji@0 34 access control rights and clarifies which rights are required for
yuuji@0 35 different IMAP commands.
yuuji@0 36
yuuji@0 37
yuuji@0 38
yuuji@0 39
yuuji@0 40
yuuji@0 41
yuuji@0 42
yuuji@0 43
yuuji@0 44
yuuji@0 45
yuuji@0 46
yuuji@0 47
yuuji@0 48
yuuji@0 49
yuuji@0 50
yuuji@0 51
yuuji@0 52
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Melnikov Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 4314 IMAP ACL December 2005
yuuji@0 61
yuuji@0 62
yuuji@0 63 Table of Contents
yuuji@0 64
yuuji@0 65 1. Introduction and Overview .......................................3
yuuji@0 66 1.1. Conventions Used in This Document ..........................3
yuuji@0 67 2. Access Control ..................................................3
yuuji@0 68 2.1. Standard Rights ............................................5
yuuji@0 69 2.1.1. Obsolete Rights .....................................5
yuuji@0 70 2.2. Rights Defined in RFC 2086 .................................8
yuuji@0 71 3. Access control management commands and responses ................8
yuuji@0 72 3.1. SETACL Command .............................................8
yuuji@0 73 3.2. DELETEACL Command ..........................................9
yuuji@0 74 3.3. GETACL Command ............................................10
yuuji@0 75 3.4. LISTRIGHTS Command ........................................10
yuuji@0 76 3.5. MYRIGHTS Command ..........................................11
yuuji@0 77 3.6. ACL Response ..............................................11
yuuji@0 78 3.7. LISTRIGHTS Response .......................................12
yuuji@0 79 3.8. MYRIGHTS Response .........................................12
yuuji@0 80 4. Rights Required to Perform Different IMAP4rev1 Commands ........12
yuuji@0 81 5. Other Considerations ...........................................17
yuuji@0 82 5.1. Additional Requirements and Implementation Notes ..........17
yuuji@0 83 5.1.1. Servers ............................................17
yuuji@0 84 5.1.2. Clients ............................................18
yuuji@0 85 5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY
yuuji@0 86 Response Codes ............................................19
yuuji@0 87 6. Security Considerations ........................................20
yuuji@0 88 7. Formal Syntax ..................................................21
yuuji@0 89 8. IANA Considerations ............................................22
yuuji@0 90 9. Internationalization Considerations ............................22
yuuji@0 91 Appendix A. Changes since RFC 2086 ................................23
yuuji@0 92 Appendix B. Compatibility with RFC 2086 ...........................24
yuuji@0 93 Appendix C. Known Deficiencies ....................................24
yuuji@0 94 Appendix D. Acknowledgements ......................................25
yuuji@0 95 Normative References ..............................................25
yuuji@0 96 Informative References ............................................25
yuuji@0 97
yuuji@0 98
yuuji@0 99
yuuji@0 100
yuuji@0 101
yuuji@0 102
yuuji@0 103
yuuji@0 104
yuuji@0 105
yuuji@0 106
yuuji@0 107
yuuji@0 108
yuuji@0 109
yuuji@0 110
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Melnikov Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 4314 IMAP ACL December 2005
yuuji@0 117
yuuji@0 118
yuuji@0 119 1. Introduction and Overview
yuuji@0 120
yuuji@0 121 The ACL (Access Control List) extension of the Internet Message
yuuji@0 122 Access Protocol [IMAP4] permits mailbox access control lists to be
yuuji@0 123 retrieved and manipulated through the IMAP protocol.
yuuji@0 124
yuuji@0 125 This document is a revision of RFC 2086 [RFC2086]. It tries to
yuuji@0 126 clarify different ambiguities in RFC 2086, in particular, the use of
yuuji@0 127 UTF-8 [UTF-8] in access identifiers, which rights are required for
yuuji@0 128 different IMAP4 commands, and how READ-WRITE/READ-ONLY response codes
yuuji@0 129 are related to ACL.
yuuji@0 130
yuuji@0 131 1.1. Conventions Used in This Document
yuuji@0 132
yuuji@0 133 In examples, "C:" and "S:" indicate lines sent by the client and
yuuji@0 134 server respectively.
yuuji@0 135
yuuji@0 136 In all examples "/" character is used as hierarchy separator.
yuuji@0 137
yuuji@0 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
yuuji@0 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
yuuji@0 140 document are to be interpreted as described in RFC 2119 [KEYWORDS].
yuuji@0 141
yuuji@0 142 The phrase "ACL server" is just a shortcut for saying "IMAP server
yuuji@0 143 that supports ACL extension as defined in this document".
yuuji@0 144
yuuji@0 145 2. Access Control
yuuji@0 146
yuuji@0 147 The ACL extension is present in any IMAP4 implementation that returns
yuuji@0 148 "ACL" as one of the supported capabilities to the CAPABILITY command.
yuuji@0 149
yuuji@0 150 A server implementation conformant to this document MUST also return
yuuji@0 151 rights (see below) not defined in Section 2.2 in the "RIGHTS="
yuuji@0 152 capability.
yuuji@0 153
yuuji@0 154 An access control list is a set of <access identifier,rights> pairs.
yuuji@0 155 An ACL applies to a mailbox name.
yuuji@0 156
yuuji@0 157 Access identifier (or just "identifier") is a UTF-8 [UTF-8] string.
yuuji@0 158 The identifier "anyone" is reserved to refer to the universal
yuuji@0 159 identity (all authentications, including anonymous). All user name
yuuji@0 160 strings accepted by the LOGIN or AUTHENTICATE commands to
yuuji@0 161 authenticate to the IMAP server are reserved as identifiers for the
yuuji@0 162 corresponding users. Identifiers starting with a dash ("-") are
yuuji@0 163 reserved for "negative rights", described below. All other
yuuji@0 164 identifier strings are interpreted in an implementation-defined
yuuji@0 165 manner.
yuuji@0 166
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Melnikov Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 4314 IMAP ACL December 2005
yuuji@0 173
yuuji@0 174
yuuji@0 175 Rights is a string listing a (possibly empty) set of alphanumeric
yuuji@0 176 characters, each character listing a set of operations that is being
yuuji@0 177 controlled. Lowercase letters are reserved for "standard" rights,
yuuji@0 178 listed in Section 2.1. (Note that for compatibility with deployed
yuuji@0 179 clients and servers uppercase rights are not allowed.) The set of
yuuji@0 180 standard rights can only be extended by a standards-track document.
yuuji@0 181 Digits are reserved for implementation- or site-defined rights.
yuuji@0 182
yuuji@0 183 An implementation MAY tie rights together or MAY force rights to
yuuji@0 184 always or never be granted to particular identifiers. For example,
yuuji@0 185 in an implementation that uses UNIX mode bits, the rights "swite" are
yuuji@0 186 tied, the "a" right is always granted to the owner of a mailbox and
yuuji@0 187 is never granted to another user. If rights are tied in an
yuuji@0 188 implementation, the implementation must be conservative in granting
yuuji@0 189 rights in response to SETACL commands--unless all rights in a tied
yuuji@0 190 set are specified, none of that set should be included in the ACL
yuuji@0 191 entry for that identifier. A client can discover the set of rights
yuuji@0 192 that may be granted to a given identifier in the ACL for a given
yuuji@0 193 mailbox name by using the LISTRIGHTS command.
yuuji@0 194
yuuji@0 195 It is possible for multiple identifiers in an access control list to
yuuji@0 196 apply to a given user. For example, an ACL may include rights to be
yuuji@0 197 granted to the identifier matching the user, one or more
yuuji@0 198 implementation-defined identifiers matching groups that include the
yuuji@0 199 user, and/or the identifier "anyone". How these rights are combined
yuuji@0 200 to determine the user's access is implementation defined. An
yuuji@0 201 implementation may choose, for example, to use the union of the
yuuji@0 202 rights granted to the applicable identifiers. An implementation may
yuuji@0 203 instead choose, for example, to use only those rights granted to the
yuuji@0 204 most specific identifier present in the ACL. A client can determine
yuuji@0 205 the set of rights granted to the logged-in user for a given mailbox
yuuji@0 206 name by using the MYRIGHTS command.
yuuji@0 207
yuuji@0 208 When an identifier in an ACL starts with a dash ("-"), that indicates
yuuji@0 209 that associated rights are to be removed from the identifier prefixed
yuuji@0 210 by the dash. This is referred to as a "negative right". This
yuuji@0 211 differs from DELETEACL in that a negative right is added to the ACL
yuuji@0 212 and is a part of the calculation of the rights.
yuuji@0 213
yuuji@0 214 Let's assume that an identifier "fred" refers to a user with login
yuuji@0 215 "fred". If the identifier "-fred" is granted the "w" right, that
yuuji@0 216 indicates that the "w" right is to be removed from users matching the
yuuji@0 217 identifier "fred", even though the user "fred" might have the "w"
yuuji@0 218 right as a consequence of some other identifier in the ACL. A
yuuji@0 219 DELETEACL of "fred" simply deletes the identifier "fred" from the
yuuji@0 220 ACL; it does not affect any rights that the user "fred" may get from
yuuji@0 221 another entry in the ACL, in particular it doesn't affect rights
yuuji@0 222 granted to the identifier "-fred".
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Melnikov Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 4314 IMAP ACL December 2005
yuuji@0 229
yuuji@0 230
yuuji@0 231 Server implementations are not required to support "negative right"
yuuji@0 232 identifiers.
yuuji@0 233
yuuji@0 234 2.1. Standard Rights
yuuji@0 235
yuuji@0 236 The currently defined standard rights are (note that the list below
yuuji@0 237 doesn't list all commands that use a particular right):
yuuji@0 238
yuuji@0 239 l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE
yuuji@0 240 mailbox)
yuuji@0 241 r - read (SELECT the mailbox, perform STATUS)
yuuji@0 242 s - keep seen/unseen information across sessions (set or clear
yuuji@0 243 \SEEN flag via STORE, also set \SEEN during APPEND/COPY/
yuuji@0 244 FETCH BODY[...])
yuuji@0 245 w - write (set or clear flags other than \SEEN and \DELETED via
yuuji@0 246 STORE, also set them during APPEND/COPY)
yuuji@0 247 i - insert (perform APPEND, COPY into mailbox)
yuuji@0 248 p - post (send mail to submission address for mailbox,
yuuji@0 249 not enforced by IMAP4 itself)
yuuji@0 250 k - create mailboxes (CREATE new sub-mailboxes in any
yuuji@0 251 implementation-defined hierarchy, parent mailbox for the new
yuuji@0 252 mailbox name in RENAME)
yuuji@0 253 x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
yuuji@0 254 t - delete messages (set or clear \DELETED flag via STORE, set
yuuji@0 255 \DELETED flag during APPEND/COPY)
yuuji@0 256 e - perform EXPUNGE and expunge as a part of CLOSE
yuuji@0 257 a - administer (perform SETACL/DELETEACL/GETACL/LISTRIGHTS)
yuuji@0 258
yuuji@0 259 2.1.1. Obsolete Rights
yuuji@0 260
yuuji@0 261 Due to ambiguity in RFC 2086, some existing RFC 2086 server
yuuji@0 262 implementations use the "c" right to control the DELETE command.
yuuji@0 263 Others chose to use the "d" right to control the DELETE command. For
yuuji@0 264 the former group, let's define the "create" right as union of the "k"
yuuji@0 265 and "x" rights, and the "delete" right as union of the "e" and "t"
yuuji@0 266 rights. For the latter group, let's define the "create" rights as a
yuuji@0 267 synonym to the "k" right, and the "delete" right as union of the "e",
yuuji@0 268 "t", and "x" rights.
yuuji@0 269
yuuji@0 270 For compatibility with RFC 2086, this section defines two virtual
yuuji@0 271 rights "d" and "c".
yuuji@0 272
yuuji@0 273 If a client includes the "d" right in a rights list, then it MUST be
yuuji@0 274 treated as if the client had included every member of the "delete"
yuuji@0 275 right. (It is not an error for a client to specify both the "d"
yuuji@0 276 right and one or more members of the "delete" right, but the effect
yuuji@0 277 is no different than if just the "d" right or all members of the
yuuji@0 278 "delete" right had been specified.)
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Melnikov Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 4314 IMAP ACL December 2005
yuuji@0 285
yuuji@0 286
yuuji@0 287 When any of the "delete" member rights is set in a list of rights,
yuuji@0 288 the server MUST also include the "d" right when returning the list in
yuuji@0 289 a MYRIGHTS or ACL response. This is to enable older clients
yuuji@0 290 conforming to RFC 2086 to work with newer servers. (*)
yuuji@0 291
yuuji@0 292 Example: C: A001 SeTacl INBOX/Drafts David lrswida
yuuji@0 293 S: A001 OK Setacl complete
yuuji@0 294
yuuji@0 295 The client has specified the "d" right in the SETACL command above
yuuji@0 296 and it expands to "et" on the server:
yuuji@0 297
yuuji@0 298 C: A002 getacl INBOX/Drafts
yuuji@0 299 S: * ACL INBOX Fred rwipslxcetda David lrswideta
yuuji@0 300 S: A002 OK Getacl complete
yuuji@0 301
yuuji@0 302 If the identifier specified in the LISTRIGHTS command can be granted
yuuji@0 303 any of the "delete" member rights on a mailbox, then the server MUST
yuuji@0 304 include the "d" right in the corresponding LISTRIGHTS response. (*)
yuuji@0 305 If the member rights aren't tied to non-member rights, then the "d"
yuuji@0 306 right is returned by itself in the LISTRIGHTS response. If any of
yuuji@0 307 the member rights needs to be tied to one (or more) non-member right,
yuuji@0 308 then the "d" right and all of the member rights need to be tied to
yuuji@0 309 the same non-member right(s) (**).
yuuji@0 310
yuuji@0 311 If a client includes the "c" right in a rights list, then it MUST be
yuuji@0 312 treated as if the client had included every member of the "create"
yuuji@0 313 right. (It is not an error for a client to specify both the "c"
yuuji@0 314 right and one or more members of the "create" right, but the effect
yuuji@0 315 is no different than if just the "c" right or all members of the
yuuji@0 316 "create" right had been specified.)
yuuji@0 317
yuuji@0 318 When any of the "create" member rights is set in a list of rights,
yuuji@0 319 the server MUST also include the "c" right when returning the list in
yuuji@0 320 a MYRIGHTS or ACL response. This is to enable older clients
yuuji@0 321 conforming to RFC 2086 to work with newer servers. (*)
yuuji@0 322
yuuji@0 323 Example: C: A003 Setacl INBOX/Drafts Byron lrswikda
yuuji@0 324 S: A001 OK Setacl complete
yuuji@0 325 C: A002 getAcl INBOX/Drafts
yuuji@0 326 S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
yuuji@0 327 S: A002 OK Getacl complete
yuuji@0 328
yuuji@0 329 The client has specified the "d" right in the SETACL command above
yuuji@0 330 and it expands to "et" on the server: As the client has specified the
yuuji@0 331 "k" right (which is a member of the "c" right), the server also
yuuji@0 332 returns the "c" right.
yuuji@0 333
yuuji@0 334
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Melnikov Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 4314 IMAP ACL December 2005
yuuji@0 341
yuuji@0 342
yuuji@0 343 If the identifier specified in the LISTRIGHTS command can be granted
yuuji@0 344 any of the "create" member rights on a mailbox, then the server MUST
yuuji@0 345 include the "c" right in the corresponding LISTRIGHTS response. (*)
yuuji@0 346 If the member rights aren't tied to non-member rights, then the "c"
yuuji@0 347 right is returned by itself in the LISTRIGHTS response. If any of
yuuji@0 348 the member rights needs to be tied to one (or more) non-member right,
yuuji@0 349 then the "c" right and all of the member rights need to be tied to
yuuji@0 350 the same non-member right(s) (**).
yuuji@0 351
yuuji@0 352 Example: The server that ties the rights as follows:
yuuji@0 353
yuuji@0 354 lr s w i p k x t
yuuji@0 355
yuuji@0 356 and c=k
yuuji@0 357
yuuji@0 358 will return:
yuuji@0 359
yuuji@0 360 S: * LISTRIGHTS archive/imap anyone ""
yuuji@0 361 lr s w i p k x t c d
yuuji@0 362
yuuji@0 363 Example: The server that ties the rights as follows:
yuuji@0 364
yuuji@0 365 lr s w i p k xte
yuuji@0 366
yuuji@0 367 and c=k
yuuji@0 368
yuuji@0 369 will return:
yuuji@0 370
yuuji@0 371 S: * LISTRIGHTS archive/imap anyone ""
yuuji@0 372 lr s w i p k xte c d
yuuji@0 373
yuuji@0 374 Example: The server that ties the rights as follows:
yuuji@0 375
yuuji@0 376 lr s w i p k x te
yuuji@0 377
yuuji@0 378 and c=k
yuuji@0 379
yuuji@0 380 will return:
yuuji@0 381
yuuji@0 382 S: * LISTRIGHTS archive/imap anyone ""
yuuji@0 383 lr s w i p k c x te d
yuuji@0 384
yuuji@0 385 Example: The server that ties the rights as follows:
yuuji@0 386
yuuji@0 387 lr swte i p k x
yuuji@0 388
yuuji@0 389 and c=kx
yuuji@0 390
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Melnikov Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 4314 IMAP ACL December 2005
yuuji@0 397
yuuji@0 398
yuuji@0 399 will return:
yuuji@0 400
yuuji@0 401 S: * LISTRIGHTS archive/imap anyone ""
yuuji@0 402 lr swted i p k x c
yuuji@0 403
yuuji@0 404 (*) Clients conforming to this document MUST ignore the virtual "d"
yuuji@0 405 and "c" rights in MYRIGHTS, ACL, and LISTRIGHTS responses.
yuuji@0 406
yuuji@0 407 (**) The IMAPEXT Working Group has debated this issue in great length
yuuji@0 408 and after reviewing existing ACL implementations concluded that
yuuji@0 409 this is a reasonable restriction.
yuuji@0 410
yuuji@0 411 2.2. Rights Defined in RFC 2086
yuuji@0 412
yuuji@0 413 The "RIGHTS=" capability MUST NOT include any of the rights defined
yuuji@0 414 in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the
yuuji@0 415 digits ("0" .. "9").
yuuji@0 416
yuuji@0 417 3. Access control management commands and responses
yuuji@0 418
yuuji@0 419 Servers, when processing a command that has an identifier as a
yuuji@0 420 parameter (i.e., any of SETACL, DELETEACL, and LISTRIGHTS commands),
yuuji@0 421 SHOULD first prepare the received identifier using "SASLprep" profile
yuuji@0 422 [SASLprep] of the "stringprep" algorithm [Stringprep]. If the
yuuji@0 423 preparation of the identifier fails or results in an empty string,
yuuji@0 424 the server MUST refuse to perform the command with a BAD response.
yuuji@0 425 Note that Section 6 recommends additional identifier's verification
yuuji@0 426 steps.
yuuji@0 427
yuuji@0 428 3.1. SETACL Command
yuuji@0 429
yuuji@0 430 Arguments: mailbox name
yuuji@0 431 identifier
yuuji@0 432 access right modification
yuuji@0 433
yuuji@0 434 Data: no specific data for this command
yuuji@0 435
yuuji@0 436 Result: OK - setacl completed
yuuji@0 437 NO - setacl failure: can't set acl
yuuji@0 438 BAD - arguments invalid
yuuji@0 439
yuuji@0 440 The SETACL command changes the access control list on the specified
yuuji@0 441 mailbox so that the specified identifier is granted permissions as
yuuji@0 442 specified in the third argument.
yuuji@0 443
yuuji@0 444 The third argument is a string containing an optional plus ("+") or
yuuji@0 445 minus ("-") prefix, followed by zero or more rights characters. If
yuuji@0 446 the string starts with a plus, the following rights are added to any
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Melnikov Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 4314 IMAP ACL December 2005
yuuji@0 453
yuuji@0 454
yuuji@0 455 existing rights for the identifier. If the string starts with a
yuuji@0 456 minus, the following rights are removed from any existing rights for
yuuji@0 457 the identifier. If the string does not start with a plus or minus,
yuuji@0 458 the rights replace any existing rights for the identifier.
yuuji@0 459
yuuji@0 460 Note that an unrecognized right MUST cause the command to return the
yuuji@0 461 BAD response. In particular, the server MUST NOT silently ignore
yuuji@0 462 unrecognized rights.
yuuji@0 463
yuuji@0 464 Example: C: A001 GETACL INBOX/Drafts
yuuji@0 465 S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswi
yuuji@0 466 S: A001 OK Getacl complete
yuuji@0 467 C: A002 SETACL INBOX/Drafts Chris +cda
yuuji@0 468 S: A002 OK Setacl complete
yuuji@0 469 C: A003 GETACL INBOX/Drafts
yuuji@0 470 S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswicdakxet
yuuji@0 471 S: A003 OK Getacl complete
yuuji@0 472
yuuji@0 473
yuuji@0 474 C: A035 SETACL INBOX/Drafts John lrQswicda
yuuji@0 475 S: A035 BAD Uppercase rights are not allowed
yuuji@0 476
yuuji@0 477
yuuji@0 478 C: A036 SETACL INBOX/Drafts John lrqswicda
yuuji@0 479 S: A036 BAD The q right is not supported
yuuji@0 480
yuuji@0 481 3.2. DELETEACL Command
yuuji@0 482
yuuji@0 483 Arguments: mailbox name
yuuji@0 484 identifier
yuuji@0 485
yuuji@0 486 Data: no specific data for this command
yuuji@0 487
yuuji@0 488 Result: OK - deleteacl completed
yuuji@0 489 NO - deleteacl failure: can't delete acl
yuuji@0 490 BAD - arguments invalid
yuuji@0 491
yuuji@0 492 The DELETEACL command removes any <identifier,rights> pair for the
yuuji@0 493 specified identifier from the access control list for the specified
yuuji@0 494 mailbox.
yuuji@0 495
yuuji@0 496 Example: C: B001 getacl INBOX
yuuji@0 497 S: * ACL INBOX Fred rwipslxetad -Fred wetd $team w
yuuji@0 498 S: B001 OK Getacl complete
yuuji@0 499 C: B002 DeleteAcl INBOX Fred
yuuji@0 500 S: B002 OK Deleteacl complete
yuuji@0 501
yuuji@0 502
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Melnikov Standards Track [Page 9]
yuuji@0 507
yuuji@0 508 RFC 4314 IMAP ACL December 2005
yuuji@0 509
yuuji@0 510
yuuji@0 511 C: B003 GETACL INBOX
yuuji@0 512 S: * ACL INBOX -Fred wetd $team w
yuuji@0 513 S: B003 OK Getacl complete
yuuji@0 514
yuuji@0 515 3.3. GETACL Command
yuuji@0 516
yuuji@0 517 Arguments: mailbox name
yuuji@0 518
yuuji@0 519 Data: untagged responses: ACL
yuuji@0 520
yuuji@0 521 Result: OK - getacl completed
yuuji@0 522 NO - getacl failure: can't get acl
yuuji@0 523 BAD - arguments invalid
yuuji@0 524
yuuji@0 525 The GETACL command returns the access control list for mailbox in an
yuuji@0 526 untagged ACL response.
yuuji@0 527
yuuji@0 528 Some implementations MAY permit multiple forms of an identifier to
yuuji@0 529 reference the same IMAP account. Usually, such implementations will
yuuji@0 530 have a canonical form that is stored internally. An ACL response
yuuji@0 531 caused by a GETACL command MAY include a canonicalized form of the
yuuji@0 532 identifier that might be different from the one used in the
yuuji@0 533 corresponding SETACL command.
yuuji@0 534
yuuji@0 535 Example: C: A002 GETACL INBOX
yuuji@0 536 S: * ACL INBOX Fred rwipsldexta
yuuji@0 537 S: A002 OK Getacl complete
yuuji@0 538
yuuji@0 539 3.4. LISTRIGHTS Command
yuuji@0 540
yuuji@0 541 Arguments: mailbox name
yuuji@0 542 identifier
yuuji@0 543
yuuji@0 544 Data: untagged responses: LISTRIGHTS
yuuji@0 545
yuuji@0 546 Result: OK - listrights completed
yuuji@0 547 NO - listrights failure: can't get rights list
yuuji@0 548 BAD - arguments invalid
yuuji@0 549
yuuji@0 550 The LISTRIGHTS command takes a mailbox name and an identifier and
yuuji@0 551 returns information about what rights can be granted to the
yuuji@0 552 identifier in the ACL for the mailbox.
yuuji@0 553
yuuji@0 554 Some implementations MAY permit multiple forms of an identifier to
yuuji@0 555 reference the same IMAP account. Usually, such implementations will
yuuji@0 556 have a canonical form that is stored internally. A LISTRIGHTS
yuuji@0 557
yuuji@0 558
yuuji@0 559
yuuji@0 560
yuuji@0 561
yuuji@0 562 Melnikov Standards Track [Page 10]
yuuji@0 563
yuuji@0 564 RFC 4314 IMAP ACL December 2005
yuuji@0 565
yuuji@0 566
yuuji@0 567 response caused by a LISTRIGHTS command MUST always return the same
yuuji@0 568 form of an identifier as specified by the client. This is to allow
yuuji@0 569 the client to correlate the response with the command.
yuuji@0 570
yuuji@0 571 Example: C: a001 LISTRIGHTS ~/Mail/saved smith
yuuji@0 572 S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte
yuuji@0 573 S: a001 OK Listrights completed
yuuji@0 574
yuuji@0 575 Example: C: a005 listrights archive/imap anyone
yuuji@0 576 S: * LISTRIGHTS archive.imap anyone ""
yuuji@0 577 l r s w i p k x t e c d a 0 1 2 3 4 5 6 7 8 9
yuuji@0 578 S: a005 Listrights successful
yuuji@0 579
yuuji@0 580 3.5. MYRIGHTS Command
yuuji@0 581
yuuji@0 582 Arguments: mailbox name
yuuji@0 583
yuuji@0 584 Data: untagged responses: MYRIGHTS
yuuji@0 585
yuuji@0 586 Result: OK - myrights completed
yuuji@0 587 NO - myrights failure: can't get rights
yuuji@0 588 BAD - arguments invalid
yuuji@0 589
yuuji@0 590 The MYRIGHTS command returns the set of rights that the user has to
yuuji@0 591 mailbox in an untagged MYRIGHTS reply.
yuuji@0 592
yuuji@0 593 Example: C: A003 MYRIGHTS INBOX
yuuji@0 594 S: * MYRIGHTS INBOX rwiptsldaex
yuuji@0 595 S: A003 OK Myrights complete
yuuji@0 596
yuuji@0 597 3.6. ACL Response
yuuji@0 598
yuuji@0 599 Data: mailbox name
yuuji@0 600 zero or more identifier rights pairs
yuuji@0 601
yuuji@0 602 The ACL response occurs as a result of a GETACL command. The first
yuuji@0 603 string is the mailbox name for which this ACL applies. This is
yuuji@0 604 followed by zero or more pairs of strings; each pair contains the
yuuji@0 605 identifier for which the entry applies followed by the set of rights
yuuji@0 606 that the identifier has.
yuuji@0 607
yuuji@0 608 Section 2.1.1 details additional server requirements related to
yuuji@0 609 handling of the virtual "d" and "c" rights.
yuuji@0 610
yuuji@0 611
yuuji@0 612
yuuji@0 613
yuuji@0 614
yuuji@0 615
yuuji@0 616
yuuji@0 617
yuuji@0 618 Melnikov Standards Track [Page 11]
yuuji@0 619
yuuji@0 620 RFC 4314 IMAP ACL December 2005
yuuji@0 621
yuuji@0 622
yuuji@0 623 3.7. LISTRIGHTS Response
yuuji@0 624
yuuji@0 625 Data: mailbox name
yuuji@0 626 identifier
yuuji@0 627 required rights
yuuji@0 628 list of optional rights
yuuji@0 629
yuuji@0 630 The LISTRIGHTS response occurs as a result of a LISTRIGHTS command.
yuuji@0 631 The first two strings are the mailbox name and identifier for which
yuuji@0 632 this rights list applies. Following the identifier is a string
yuuji@0 633 containing the (possibly empty) set of rights the identifier will
yuuji@0 634 always be granted in the mailbox.
yuuji@0 635
yuuji@0 636 Following this are zero or more strings each containing a set of
yuuji@0 637 rights the identifier can be granted in the mailbox. Rights
yuuji@0 638 mentioned in the same string are tied together. The server MUST
yuuji@0 639 either grant all tied rights to the identifier in the mailbox or
yuuji@0 640 grant none. Section 2.1.1 details additional server requirements
yuuji@0 641 related to handling of the virtual "d" and "c" rights.
yuuji@0 642
yuuji@0 643 The same right MUST NOT be listed more than once in the LISTRIGHTS
yuuji@0 644 command.
yuuji@0 645
yuuji@0 646 3.8. MYRIGHTS Response
yuuji@0 647
yuuji@0 648 Data: mailbox name
yuuji@0 649 rights
yuuji@0 650
yuuji@0 651 The MYRIGHTS response occurs as a result of a MYRIGHTS command. The
yuuji@0 652 first string is the mailbox name for which these rights apply. The
yuuji@0 653 second string is the set of rights that the client has.
yuuji@0 654
yuuji@0 655 Section 2.1.1 details additional server requirements related to
yuuji@0 656 handling of the virtual "d" and "c" rights.
yuuji@0 657
yuuji@0 658 4. Rights Required to Perform Different IMAP4rev1 Commands
yuuji@0 659
yuuji@0 660 Before executing a command, an ACL-compliant server MUST check which
yuuji@0 661 rights are required to perform it. This section groups command by
yuuji@0 662 functions they perform and list the rights required. It also gives
yuuji@0 663 the detailed description of any special processing required.
yuuji@0 664
yuuji@0 665 For the purpose of this section the UID counterpart of a command is
yuuji@0 666 considered to be the same command, e.g., both UID COPY and COPY
yuuji@0 667 commands require the same set of rights.
yuuji@0 668
yuuji@0 669
yuuji@0 670
yuuji@0 671
yuuji@0 672
yuuji@0 673
yuuji@0 674 Melnikov Standards Track [Page 12]
yuuji@0 675
yuuji@0 676 RFC 4314 IMAP ACL December 2005
yuuji@0 677
yuuji@0 678
yuuji@0 679 The table below summarizes different rights or their combinations
yuuji@0 680 that are required in order to perform different IMAP operations. As
yuuji@0 681 it is not always possible to express complex right checking and
yuuji@0 682 interactions, the description after the table should be used as the
yuuji@0 683 primary reference.
yuuji@0 684
yuuji@0 685 +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
yuuji@0 686 |Operations\Rights | l | r | s | w | i | k | x | t | e | a |Any|Non|
yuuji@0 687 +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
yuuji@0 688 | commands in authenticated state |
yuuji@0 689 +-------------------------------------------------------------------+
yuuji@0 690 | LIST | + | | | | | | | | | | | |
yuuji@0 691 | SUBSCRIBE | * | | | | | | | | | | | * |
yuuji@0 692 | UNSUBSCRIBE | | | | | | | | | | | | + |
yuuji@0 693 | LSUB | * | | | | | | | | | | | * |
yuuji@0 694 |CREATE (for parent)| | | | | | + | | | | | | |
yuuji@0 695 | DELETE | | ? | | | | | + | ? | ? | | | |
yuuji@0 696 | RENAME | | | | | | + | + | | | | | |
yuuji@0 697 | SELECT/EXAMINE | | + | | | | | | | | | | |
yuuji@0 698 | STATUS | | + | | | | | | | | | | |
yuuji@0 699 | SETACL/DELETEACL | | | | | | | | | | + | | |
yuuji@0 700 | GETACL/LISTRIGHTS | | | | | | | | | | + | | |
yuuji@0 701 | MYRIGHTS | | | | | | | | | | | + | |
yuuji@0 702 | APPEND | | | ? | ? | + | | | ? | | | | |
yuuji@0 703 +-------------------------------------------------------------------+
yuuji@0 704 | commands in selected state |
yuuji@0 705 +-------------------------------------------------------------------+
yuuji@0 706 | COPY | | | ? | ? | + | | | ? | | | | |
yuuji@0 707 | EXPUNGE | | | | | | | | | + | | | |
yuuji@0 708 | CLOSE | | | | | | | | | ? | | | |
yuuji@0 709 | FETCH | | | ? | | | | | | | | | |
yuuji@0 710 | STORE flags | | | ? | ? | | | | ? | | | | |
yuuji@0 711 +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
yuuji@0 712
yuuji@0 713 Note: for all commands in the selected state, the "r" is implied,
yuuji@0 714 because it is required to SELECT/EXAMINE a mailbox. Servers are not
yuuji@0 715 required to check presence of the "r" right once a mailbox is
yuuji@0 716 successfully selected.
yuuji@0 717
yuuji@0 718 Legend:
yuuji@0 719 + - The right is required
yuuji@0 720 * - Only one of the rights marked with * is required
yuuji@0 721 (see description below)
yuuji@0 722 ? - The right is OPTIONAL (see description below)
yuuji@0 723 "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is
yuuji@0 724 required
yuuji@0 725 "Non" - No rights required to perform the command
yuuji@0 726
yuuji@0 727
yuuji@0 728
yuuji@0 729
yuuji@0 730 Melnikov Standards Track [Page 13]
yuuji@0 731
yuuji@0 732 RFC 4314 IMAP ACL December 2005
yuuji@0 733
yuuji@0 734
yuuji@0 735 Listing and subscribing/unsubscribing mailboxes:
yuuji@0 736 LIST - "l" right is required. However, unlike other commands
yuuji@0 737 (e.g., SELECT) the server MUST NOT return a NO response if it
yuuji@0 738 can't list a mailbox.
yuuji@0 739 Note that if the user has "l" right to a mailbox "A/B", but not to
yuuji@0 740 its parent mailbox "A", the LIST command should behave as if the
yuuji@0 741 mailbox "A" doesn't exist, for example:
yuuji@0 742
yuuji@0 743 C: A777 LIST "" *
yuuji@0 744 S: * LIST (\NoInferiors) "/" "A/B"
yuuji@0 745 S: * LIST () "/" "C"
yuuji@0 746 S: * LIST (\NoInferiors) "/" "C/D"
yuuji@0 747 S: A777 OK LIST completed
yuuji@0 748
yuuji@0 749
yuuji@0 750 SUBSCRIBE - "l" right is required only if the server checks for
yuuji@0 751 mailbox existence when performing SUBSCRIBE.
yuuji@0 752
yuuji@0 753 UNSUBSCRIBE - no rights required to perform this operation.
yuuji@0 754
yuuji@0 755 LSUB - "l" right is required only if the server checks for mailbox
yuuji@0 756 existence when performing SUBSCRIBE. However, unlike other
yuuji@0 757 commands (e.g., SELECT) the server MUST NOT return a NO response
yuuji@0 758 if it can't list a subscribed mailbox.
yuuji@0 759
yuuji@0 760 Mailbox management:
yuuji@0 761 CREATE - "k" right on a nearest existing parent mailbox. When a
yuuji@0 762 new mailbox is created, it SHOULD inherit the ACL from the parent
yuuji@0 763 mailbox (if one exists) in the defined hierarchy.
yuuji@0 764
yuuji@0 765 DELETE - "x" right on the mailbox. Note that some servers don't
yuuji@0 766 allow to delete a non-empty mailbox. If this is the case, the
yuuji@0 767 user would also need "r", "e", and "t" rights, in order to open
yuuji@0 768 the mailbox and empty it.
yuuji@0 769
yuuji@0 770 The DELETE command MUST delete the ACL associated with the deleted
yuuji@0 771 mailbox.
yuuji@0 772
yuuji@0 773 RENAME - Moving a mailbox from one parent to another requires the
yuuji@0 774 "x" right on the mailbox itself and the "k" right for the new
yuuji@0 775 parent. For example, if the user wants to rename the mailbox
yuuji@0 776 named "A/B/C" to "D/E", the user must have the "x" right for the
yuuji@0 777 mailbox "A/B/C" and the "k" right for the mailbox "D".
yuuji@0 778 The RENAME command SHOULD NOT change the ACLs on the renamed
yuuji@0 779 mailbox and submailboxes.
yuuji@0 780
yuuji@0 781
yuuji@0 782
yuuji@0 783
yuuji@0 784
yuuji@0 785
yuuji@0 786 Melnikov Standards Track [Page 14]
yuuji@0 787
yuuji@0 788 RFC 4314 IMAP ACL December 2005
yuuji@0 789
yuuji@0 790
yuuji@0 791 Copying or appending messages:
yuuji@0 792 Before performing a COPY/APPEND command, the server MUST check if
yuuji@0 793 the user has "i" right for the target mailbox. If the user
yuuji@0 794 doesn't have "i" right, the operation fails. Otherwise for each
yuuji@0 795 copied/appended message the server MUST check if the user has
yuuji@0 796 "t" right - when the message has \Deleted flag set
yuuji@0 797 "s" right - when the message has \Seen flag set
yuuji@0 798 "w" right - for all other message flags.
yuuji@0 799 Only when the user has a particular right are the corresponding
yuuji@0 800 flags stored for the newly created message. The server MUST NOT
yuuji@0 801 fail a COPY/APPEND if the user has no rights to set a particular
yuuji@0 802 flag.
yuuji@0 803
yuuji@0 804 Example: C: A003 MYRIGHTS TargetMailbox
yuuji@0 805 S: * MYRIGHTS TargetMailbox rwis
yuuji@0 806 S: A003 OK Myrights complete
yuuji@0 807
yuuji@0 808 C: A004 FETCH 1:3 (FLAGS)
yuuji@0 809 S: * 1 FETCH (FLAGS (\Draft \Deleted)
yuuji@0 810 S: * 2 FETCH (FLAGS (\Answered)
yuuji@0 811 S: * 3 FETCH (FLAGS ($Forwarded \Seen)
yuuji@0 812 S: A004 OK Fetch Completed
yuuji@0 813
yuuji@0 814 C: A005 COPY 1:3 TargetMailbox
yuuji@0 815 S: A005 OK Copy completed
yuuji@0 816
yuuji@0 817 C: A006 SELECT TargetMailbox
yuuji@0 818 ...
yuuji@0 819 S: A006 Select Completed
yuuji@0 820
yuuji@0 821 Let's assume that the copied messages received message numbers
yuuji@0 822 77:79.
yuuji@0 823
yuuji@0 824 C: A007 FETCH 77:79 (FLAGS)
yuuji@0 825 S: * 77 FETCH (FLAGS (\Draft))
yuuji@0 826 S: * 78 FETCH (FLAGS (\Answered))
yuuji@0 827 S: * 79 FETCH (FLAGS ($Forwarded \Seen))
yuuji@0 828 S: A007 OK Fetch Completed
yuuji@0 829
yuuji@0 830 \Deleted flag was lost on COPY, as the user has no "t" right in
yuuji@0 831 the target mailbox.
yuuji@0 832 If the MYRIGHTS command with the tag A003 would have returned:
yuuji@0 833
yuuji@0 834 S: * MYRIGHTS TargetMailbox rsti
yuuji@0 835
yuuji@0 836 the response from the FETCH with the tag A007 would have been:
yuuji@0 837
yuuji@0 838 C: A007 FETCH 77:79 (FLAGS)
yuuji@0 839
yuuji@0 840
yuuji@0 841
yuuji@0 842 Melnikov Standards Track [Page 15]
yuuji@0 843
yuuji@0 844 RFC 4314 IMAP ACL December 2005
yuuji@0 845
yuuji@0 846
yuuji@0 847 S: * 77 FETCH (FLAGS (\Deleted))
yuuji@0 848 S: * 78 FETCH (FLAGS ())
yuuji@0 849 S: * 79 FETCH (FLAGS (\Seen))
yuuji@0 850 S: A007 OK Fetch Completed
yuuji@0 851
yuuji@0 852 In the latter case, \Answered, $Forwarded, and \Draft flags were
yuuji@0 853 lost on COPY, as the user has no "w" right in the target mailbox.
yuuji@0 854
yuuji@0 855 Expunging the selected mailbox:
yuuji@0 856 EXPUNGE - "e" right on the selected mailbox.
yuuji@0 857
yuuji@0 858 CLOSE - "e" right on the selected mailbox. If the server is
yuuji@0 859 unable to expunge the mailbox because the user doesn't have the
yuuji@0 860 "e" right, the server MUST ignore the expunge request, close the
yuuji@0 861 mailbox, and return the tagged OK response.
yuuji@0 862
yuuji@0 863 Fetch information about a mailbox and its messages:
yuuji@0 864 SELECT/EXAMINE/STATUS - "r" right on the mailbox.
yuuji@0 865
yuuji@0 866 FETCH - A FETCH request that implies setting \Seen flag MUST NOT
yuuji@0 867 set it, if the current user doesn't have "s" right.
yuuji@0 868
yuuji@0 869 Changing flags:
yuuji@0 870 STORE - the server MUST check if the user has
yuuji@0 871 "t" right - when the user modifies \Deleted flag
yuuji@0 872 "s" right - when the user modifies \Seen flag
yuuji@0 873 "w" right - for all other message flags.
yuuji@0 874 STORE operation SHOULD NOT fail if the user has rights to modify
yuuji@0 875 at least one flag specified in the STORE, as the tagged NO
yuuji@0 876 response to a STORE command is not handled very well by deployed
yuuji@0 877 clients.
yuuji@0 878
yuuji@0 879 Changing ACLs:
yuuji@0 880 SETACL/DELETEACL - "a" right on the mailbox.
yuuji@0 881
yuuji@0 882 Reading ACLs:
yuuji@0 883 GETACL - "a" right on the mailbox.
yuuji@0 884
yuuji@0 885 MYRIGHTS - any of the following rights is required to perform the
yuuji@0 886 operation: "l", "r", "i", "k", "x", "a".
yuuji@0 887
yuuji@0 888 LISTRIGHTS - "a" right on the mailbox.
yuuji@0 889
yuuji@0 890
yuuji@0 891
yuuji@0 892
yuuji@0 893
yuuji@0 894
yuuji@0 895
yuuji@0 896
yuuji@0 897
yuuji@0 898 Melnikov Standards Track [Page 16]
yuuji@0 899
yuuji@0 900 RFC 4314 IMAP ACL December 2005
yuuji@0 901
yuuji@0 902
yuuji@0 903 5. Other Considerations
yuuji@0 904
yuuji@0 905 5.1. Additional Requirements and Implementation Notes
yuuji@0 906
yuuji@0 907 5.1.1. Servers
yuuji@0 908
yuuji@0 909 This document defines an additional capability that is used to
yuuji@0 910 announce the list of extra rights (excluding the ones defined in RFC
yuuji@0 911 2086) supported by the server. The set of rights MUST include "t",
yuuji@0 912 "e", "x", and "k". Note that the extra rights can appear in any
yuuji@0 913 order.
yuuji@0 914
yuuji@0 915 Example: C: 1 capability
yuuji@0 916 S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+
yuuji@0 917 ACL RIGHTS=texk
yuuji@0 918 S: 1 OK completed
yuuji@0 919
yuuji@0 920 Any server implementing an ACL extension MUST accurately reflect the
yuuji@0 921 current user's rights in FLAGS and PERMANENTFLAGS responses.
yuuji@0 922
yuuji@0 923 Example: C: A142 SELECT INBOX
yuuji@0 924 S: * 172 EXISTS
yuuji@0 925 S: * 1 RECENT
yuuji@0 926 S: * OK [UNSEEN 12] Message 12 is first unseen
yuuji@0 927 S: * OK [UIDVALIDITY 3857529045] UIDs valid
yuuji@0 928 S: * OK [UIDNEXT 4392] Predicted next UID
yuuji@0 929 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 930 S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
yuuji@0 931 S: A142 OK [READ-WRITE] SELECT completed
yuuji@0 932 C: A143 MYRIGHTS INBOX
yuuji@0 933 S: * MYRIGHTS INBOX lrwis
yuuji@0 934 S: A143 OK completed
yuuji@0 935
yuuji@0 936 Note that in order to get better performance the client MAY pipeline
yuuji@0 937 SELECT and MYRIGHTS commands:
yuuji@0 938
yuuji@0 939 C: A142 SELECT INBOX
yuuji@0 940 C: A143 MYRIGHTS INBOX
yuuji@0 941 S: * 172 EXISTS
yuuji@0 942 S: * 1 RECENT
yuuji@0 943 S: * OK [UNSEEN 12] Message 12 is first unseen
yuuji@0 944 S: * OK [UIDVALIDITY 3857529045] UIDs valid
yuuji@0 945 S: * OK [UIDNEXT 4392] Predicted next UID
yuuji@0 946 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 947 S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
yuuji@0 948 S: A142 OK [READ-WRITE] SELECT completed
yuuji@0 949 S: * MYRIGHTS INBOX lrwis
yuuji@0 950 S: A143 OK completed
yuuji@0 951
yuuji@0 952
yuuji@0 953
yuuji@0 954 Melnikov Standards Track [Page 17]
yuuji@0 955
yuuji@0 956 RFC 4314 IMAP ACL December 2005
yuuji@0 957
yuuji@0 958
yuuji@0 959 Servers MAY cache the rights a user has on a mailbox when the mailbox
yuuji@0 960 is selected, so that if a client's rights on a mailbox are changed
yuuji@0 961 with SETACL or DELETEACL, commands specific to the selected state
yuuji@0 962 (e.g., STORE, EXPUNGE) might not reflect the changed rights until the
yuuji@0 963 mailbox is re-selected. If the server checks the rights on each
yuuji@0 964 command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if
yuuji@0 965 they have changed. If such server detects that the user no longer
yuuji@0 966 has read access to the mailbox, it MAY send an untagged BYE response
yuuji@0 967 and close connection. It MAY also refuse to execute all commands
yuuji@0 968 specific to the selected state until the mailbox is closed; however,
yuuji@0 969 server implementors should note that most clients don't handle NO
yuuji@0 970 responses very well.
yuuji@0 971
yuuji@0 972 An ACL server MAY modify one or more ACLs for one or more identifiers
yuuji@0 973 as a side effect of modifying the ACL specified in a
yuuji@0 974 SETACL/DELETEACL. If the server does that, it MUST send untagged ACL
yuuji@0 975 response(s) to notify the client about the changes made.
yuuji@0 976
yuuji@0 977 An ACL server implementation MUST treat received ACL modification
yuuji@0 978 commands as a possible ambiguity with respect to subsequent commands
yuuji@0 979 affected by the ACL, as described in Section 5.5 of [IMAP4]. Hence a
yuuji@0 980 pipeline SETACL + MYRIGHTS is an ambiguity with respect to the
yuuji@0 981 server, meaning that the server must execute the SETACL command to
yuuji@0 982 completion before the MYRIGHTS. However, clients are permitted to
yuuji@0 983 send such a pipeline.
yuuji@0 984
yuuji@0 985 5.1.2. Clients
yuuji@0 986
yuuji@0 987 The following requirement is put on clients in order to allow for
yuuji@0 988 future extensibility. A client implementation that allows a user to
yuuji@0 989 read and update ACLs MUST preserve unrecognized rights that it
yuuji@0 990 doesn't allow the user to change. That is, if the client
yuuji@0 991
yuuji@0 992 1) can read ACLs
yuuji@0 993 and
yuuji@0 994 2) can update ACLs
yuuji@0 995 but
yuuji@0 996 3) doesn't allow the user to change the rights the client doesn't
yuuji@0 997 recognize, then it MUST preserve unrecognized rights.
yuuji@0 998
yuuji@0 999 Otherwise the client could risk unintentionally removing permissions
yuuji@0 1000 it doesn't understand.
yuuji@0 1001
yuuji@0 1002
yuuji@0 1003
yuuji@0 1004
yuuji@0 1005
yuuji@0 1006
yuuji@0 1007
yuuji@0 1008
yuuji@0 1009
yuuji@0 1010 Melnikov Standards Track [Page 18]
yuuji@0 1011
yuuji@0 1012 RFC 4314 IMAP ACL December 2005
yuuji@0 1013
yuuji@0 1014
yuuji@0 1015 5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes
yuuji@0 1016
yuuji@0 1017 A particular ACL server implementation MAY allow "shared multiuser
yuuji@0 1018 access" to some mailboxes. "Shared multiuser access" to a mailbox
yuuji@0 1019 means that multiple different users are able to access the same
yuuji@0 1020 mailbox, if they have proper access rights. "Shared multiuser
yuuji@0 1021 access" to the mailbox doesn't mean that the ACL for the mailbox is
yuuji@0 1022 currently set to allow access by multiple users. Let's denote a
yuuji@0 1023 "shared multiuser write access" as a "shared multiuser access" when a
yuuji@0 1024 user can be granted flag modification rights (any of "w", "s", or
yuuji@0 1025 "t").
yuuji@0 1026
yuuji@0 1027 Section 4 describes which rights are required for modifying different
yuuji@0 1028 flags.
yuuji@0 1029
yuuji@0 1030 If the ACL server implements some flags as shared for a mailbox
yuuji@0 1031 (i.e., the ACL for the mailbox MAY be set up so that changes to those
yuuji@0 1032 flags are visible to another user), let's call the set of rights
yuuji@0 1033 associated with these flags (as described in Section 4) for that
yuuji@0 1034 mailbox collectively as "shared flag rights". Note that the "shared
yuuji@0 1035 flag rights" set MAY be different for different mailboxes.
yuuji@0 1036
yuuji@0 1037 If the server doesn't support "shared multiuser write access" to a
yuuji@0 1038 mailbox or doesn't implement shared flags on the mailbox, "shared
yuuji@0 1039 flag rights" for the mailbox is defined to be the empty set.
yuuji@0 1040
yuuji@0 1041 Example 1: Mailbox "banan" allows "shared multiuser write access" and
yuuji@0 1042 implements flags \Deleted, \Answered, and $MDNSent as
yuuji@0 1043 shared flags. "Shared flag rights" for the mailbox "banan"
yuuji@0 1044 is a set containing flags "t" (because system flag
yuuji@0 1045 \Deleted requires "t" right) and "w" (because both
yuuji@0 1046 \Answered and $MDNSent require "w" right).
yuuji@0 1047
yuuji@0 1048 Example 2: Mailbox "apple" allows "shared multiuser write access" and
yuuji@0 1049 implements \Seen system flag as shared flag. "Shared flag
yuuji@0 1050 rights" for the mailbox "apple" contains "s" right
yuuji@0 1051 because system flag \Seen requires "s" right.
yuuji@0 1052
yuuji@0 1053 Example 3: Mailbox "pear" allows "shared multiuser write access" and
yuuji@0 1054 implements flags \Seen, \Draft as shared flags. "Shared
yuuji@0 1055 flag rights" for the mailbox "apple" is a set containing
yuuji@0 1056 flags "s" (because system flag \Seen requires "s" right)
yuuji@0 1057 and "w" (because system flag \Draft requires "w" right).
yuuji@0 1058
yuuji@0 1059 The server MUST include a READ-ONLY response code in the tagged OK
yuuji@0 1060 response to a SELECT command if none of the following rights is
yuuji@0 1061 granted to the current user:
yuuji@0 1062
yuuji@0 1063
yuuji@0 1064
yuuji@0 1065
yuuji@0 1066 Melnikov Standards Track [Page 19]
yuuji@0 1067
yuuji@0 1068 RFC 4314 IMAP ACL December 2005
yuuji@0 1069
yuuji@0 1070
yuuji@0 1071 "i", "e", and "shared flag rights"(***).
yuuji@0 1072
yuuji@0 1073 The server SHOULD include a READ-WRITE response code in the tagged OK
yuuji@0 1074 response if at least one of the "i", "e", or "shared flag
yuuji@0 1075 rights"(***) is granted to the current user.
yuuji@0 1076
yuuji@0 1077 (***) Note that a future extension to this document can extend the
yuuji@0 1078 list of rights that causes the server to return the READ-WRITE
yuuji@0 1079 response code.
yuuji@0 1080
yuuji@0 1081 Example 1 (continued): The user that has "lrs" rights for the mailbox
yuuji@0 1082 "banan". The server returns READ-ONLY
yuuji@0 1083 response code on SELECT, as none of "iewt"
yuuji@0 1084 rights is granted to the user.
yuuji@0 1085
yuuji@0 1086 Example 2 (continued): The user that has "rit" rights for the mailbox
yuuji@0 1087 "apple". The server returns READ-WRITE
yuuji@0 1088 response code on SELECT, as the user has "i"
yuuji@0 1089 right.
yuuji@0 1090
yuuji@0 1091 Example 3 (continued): The user that has "rset" rights for the
yuuji@0 1092 mailbox "pear". The server returns READ-WRITE
yuuji@0 1093 response code on SELECT, as the user has "e"
yuuji@0 1094 and "s" rights.
yuuji@0 1095
yuuji@0 1096 6. Security Considerations
yuuji@0 1097
yuuji@0 1098 An implementation MUST make sure the ACL commands themselves do not
yuuji@0 1099 give information about mailboxes with appropriately restricted ACLs.
yuuji@0 1100 For example, when a user agent executes a GETACL command on a mailbox
yuuji@0 1101 that the user has no permission to LIST, the server would respond to
yuuji@0 1102 that request with the same error that would be used if the mailbox
yuuji@0 1103 did not exist, thus revealing no existence information, much less the
yuuji@0 1104 mailbox's ACL.
yuuji@0 1105
yuuji@0 1106 IMAP clients implementing ACL that are able to modify ACLs SHOULD
yuuji@0 1107 warn a user that wants to give full access (or even just the "a"
yuuji@0 1108 right) to the special identifier "anyone".
yuuji@0 1109
yuuji@0 1110 This document relies on [SASLprep] to describe steps required to
yuuji@0 1111 perform identifier canonicalization (preparation). The preparation
yuuji@0 1112 algorithm in SASLprep was specifically designed such that its output
yuuji@0 1113 is canonical, and it is well-formed. However, due to an anomaly
yuuji@0 1114 [PR29] in the specification of Unicode normalization, canonical
yuuji@0 1115 equivalence is not guaranteed for a select few character sequences.
yuuji@0 1116 Identifiers prepared with SASLprep can be stored and returned by an
yuuji@0 1117 ACL server. The anomaly affects ACL manipulation and evaluation of
yuuji@0 1118 identifiers containing the selected character sequences. These
yuuji@0 1119
yuuji@0 1120
yuuji@0 1121
yuuji@0 1122 Melnikov Standards Track [Page 20]
yuuji@0 1123
yuuji@0 1124 RFC 4314 IMAP ACL December 2005
yuuji@0 1125
yuuji@0 1126
yuuji@0 1127 sequences, however, do not appear in well-formed text. In order to
yuuji@0 1128 address this problem, an ACL server MAY reject identifiers containing
yuuji@0 1129 sequences described in [PR29] by sending the tagged BAD response.
yuuji@0 1130 This is in addition to the requirement to reject identifiers that
yuuji@0 1131 fail SASLprep preparation as described in Section 3.
yuuji@0 1132
yuuji@0 1133 Other security considerations described in [IMAP4] are relevant to
yuuji@0 1134 this document. In particular, ACL information is sent in the clear
yuuji@0 1135 over the network unless confidentiality protection is negotiated.
yuuji@0 1136
yuuji@0 1137 This can be accomplished either by the use of STARTTLS, negotiated
yuuji@0 1138 privacy protection in the AUTHENTICATE command, or some other
yuuji@0 1139 protection mechanism.
yuuji@0 1140
yuuji@0 1141 7. Formal Syntax
yuuji@0 1142
yuuji@0 1143 Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
yuuji@0 1144 in Section 9 of [IMAP4]. Elements not defined here can be found in
yuuji@0 1145 [ABNF] and [IMAP4].
yuuji@0 1146
yuuji@0 1147 Except as noted otherwise, all alphabetic characters are case
yuuji@0 1148 insensitive. The use of uppercase or lowercase characters to define
yuuji@0 1149 token strings is for editorial clarity only. Implementations MUST
yuuji@0 1150 accept these strings in a case-insensitive fashion.
yuuji@0 1151
yuuji@0 1152 LOWER-ALPHA = %x61-7A ;; a-z
yuuji@0 1153
yuuji@0 1154 acl-data = "ACL" SP mailbox *(SP identifier SP
yuuji@0 1155 rights)
yuuji@0 1156
yuuji@0 1157 capability =/ rights-capa
yuuji@0 1158 ;;capability is defined in [IMAP4]
yuuji@0 1159
yuuji@0 1160 command-auth =/ setacl / deleteacl / getacl /
yuuji@0 1161 listrights / myrights
yuuji@0 1162 ;;command-auth is defined in [IMAP4]
yuuji@0 1163
yuuji@0 1164 deleteacl = "DELETEACL" SP mailbox SP identifier
yuuji@0 1165
yuuji@0 1166 getacl = "GETACL" SP mailbox
yuuji@0 1167
yuuji@0 1168 identifier = astring
yuuji@0 1169
yuuji@0 1170 listrights = "LISTRIGHTS" SP mailbox SP identifier
yuuji@0 1171
yuuji@0 1172 listrights-data = "LISTRIGHTS" SP mailbox SP identifier
yuuji@0 1173 SP rights *(SP rights)
yuuji@0 1174
yuuji@0 1175
yuuji@0 1176
yuuji@0 1177
yuuji@0 1178 Melnikov Standards Track [Page 21]
yuuji@0 1179
yuuji@0 1180 RFC 4314 IMAP ACL December 2005
yuuji@0 1181
yuuji@0 1182
yuuji@0 1183 mailbox-data =/ acl-data / listrights-data / myrights-data
yuuji@0 1184 ;;mailbox-data is defined in [IMAP4]
yuuji@0 1185
yuuji@0 1186 mod-rights = astring
yuuji@0 1187 ;; +rights to add, -rights to remove
yuuji@0 1188 ;; rights to replace
yuuji@0 1189
yuuji@0 1190 myrights = "MYRIGHTS" SP mailbox
yuuji@0 1191
yuuji@0 1192 myrights-data = "MYRIGHTS" SP mailbox SP rights
yuuji@0 1193
yuuji@0 1194 new-rights = 1*LOWER-ALPHA
yuuji@0 1195 ;; MUST include "t", "e", "x", and "k".
yuuji@0 1196 ;; MUST NOT include standard rights listed
yuuji@0 1197 ;; in section 2.2
yuuji@0 1198
yuuji@0 1199 rights = astring
yuuji@0 1200 ;; only lowercase ASCII letters and digits
yuuji@0 1201 ;; are allowed.
yuuji@0 1202
yuuji@0 1203 rights-capa = "RIGHTS=" new-rights
yuuji@0 1204 ;; RIGHTS=... capability
yuuji@0 1205
yuuji@0 1206 setacl = "SETACL" SP mailbox SP identifier
yuuji@0 1207 SP mod-rights
yuuji@0 1208
yuuji@0 1209 8. IANA Considerations
yuuji@0 1210
yuuji@0 1211 IMAP4 capabilities are registered by publishing a standards-track or
yuuji@0 1212 IESG-approved experimental RFC. The registry is currently located
yuuji@0 1213 at:
yuuji@0 1214
yuuji@0 1215 http://www.iana.org/assignments/imap4-capabilities
yuuji@0 1216
yuuji@0 1217 This document defines the RIGHTS= IMAP capability. IANA has added
yuuji@0 1218 this capability to the registry.
yuuji@0 1219
yuuji@0 1220 9. Internationalization Considerations
yuuji@0 1221
yuuji@0 1222 Section 3 states requirements on servers regarding
yuuji@0 1223 internationalization of identifiers.
yuuji@0 1224
yuuji@0 1225
yuuji@0 1226
yuuji@0 1227
yuuji@0 1228
yuuji@0 1229
yuuji@0 1230
yuuji@0 1231
yuuji@0 1232
yuuji@0 1233
yuuji@0 1234 Melnikov Standards Track [Page 22]
yuuji@0 1235
yuuji@0 1236 RFC 4314 IMAP ACL December 2005
yuuji@0 1237
yuuji@0 1238
yuuji@0 1239 Appendix A. Changes since RFC 2086
yuuji@0 1240
yuuji@0 1241 1. Changed the charset of "identifier" from US-ASCII to UTF-8.
yuuji@0 1242 2. Specified that mailbox deletion is controlled by the "x" right
yuuji@0 1243 and EXPUNGE is controlled by the "e" right.
yuuji@0 1244 3. Added the "t" right that controls STORE \Deleted. Redefined the
yuuji@0 1245 "d" right to be a macro for "e", "t", and possibly "x".
yuuji@0 1246 4. Added the "k" right that controls CREATE. Redefined the "c"
yuuji@0 1247 right to be a macro for "k" and possibly "x".
yuuji@0 1248 5. Specified that the "a" right also controls DELETEACL.
yuuji@0 1249 6. Specified that the "r" right also controls STATUS.
yuuji@0 1250 7. Removed the requirement to check the "r" right for CHECK, SEARCH
yuuji@0 1251 and FETCH, as this is required for SELECT/EXAMINE to be
yuuji@0 1252 successful.
yuuji@0 1253 8. LISTRIGHTS requires the "a" right on the mailbox (same as
yuuji@0 1254 SETACL).
yuuji@0 1255 9. Deleted "PARTIAL", this is a deprecated feature of RFC 1730.
yuuji@0 1256 10. Specified that the "w" right controls setting flags other than
yuuji@0 1257 \Seen and \Deleted on APPEND. Also specified that the "s" right
yuuji@0 1258 controls the \Seen flag and that the "t" right controls the
yuuji@0 1259 \Deleted flag.
yuuji@0 1260 11. Specified that SUBSCRIBE is NOT allowed with the "r" right.
yuuji@0 1261 12. Specified that the "l" right controls SUBSCRIBE.
yuuji@0 1262 13. GETACL is NOT allowed with the "r" right, even though there are
yuuji@0 1263 several implementations that allows that. If a user only has
yuuji@0 1264 "r" right, GETACL can disclose information about identifiers
yuuji@0 1265 existing on the mail system.
yuuji@0 1266 14. Clarified that RENAME requires the "k" right for the new parent
yuuji@0 1267 and the "x" right for the old name.
yuuji@0 1268 15. Added new section that describes which rights are required
yuuji@0 1269 and/or checked when performing various IMAP commands.
yuuji@0 1270 16. Added mail client security considerations when dealing with
yuuji@0 1271 special identifier "anyone".
yuuji@0 1272 17. Clarified that negative rights are not the same as DELETEACL.
yuuji@0 1273 18. Added "Compatibility with RFC 2086" section.
yuuji@0 1274 19. Added section about mapping of ACL rights to READ-WRITE and
yuuji@0 1275 READ-ONLY response codes.
yuuji@0 1276 20. Changed BNF to ABNF.
yuuji@0 1277 21. Added "Implementation Notes" section.
yuuji@0 1278 22. Updated "References" section.
yuuji@0 1279 23. Added more examples.
yuuji@0 1280 24. Clarified when the virtual "c" and "d" rights are returned in
yuuji@0 1281 ACL, MYRIGHTS, and LISTRIGHTS responses.
yuuji@0 1282
yuuji@0 1283
yuuji@0 1284
yuuji@0 1285
yuuji@0 1286
yuuji@0 1287
yuuji@0 1288
yuuji@0 1289
yuuji@0 1290 Melnikov Standards Track [Page 23]
yuuji@0 1291
yuuji@0 1292 RFC 4314 IMAP ACL December 2005
yuuji@0 1293
yuuji@0 1294
yuuji@0 1295 Appendix B. Compatibility with RFC 2086
yuuji@0 1296
yuuji@0 1297 This non-normative section gives guidelines as to how an existing RFC
yuuji@0 1298 2086 server implementation may be updated to comply with this
yuuji@0 1299 document.
yuuji@0 1300
yuuji@0 1301 This document splits the "d" right into several new different rights:
yuuji@0 1302 "t", "e", and possibly "x" (see Section 2.1.1 for more details). The
yuuji@0 1303 "d" right remains for backward-compatibility, but it is a virtual
yuuji@0 1304 right. There are two approaches for RFC 2086 server implementors to
yuuji@0 1305 handle the "d" right and the new rights that have replaced it:
yuuji@0 1306
yuuji@0 1307 a. Tie "t", "e" (and possibly "x) together - almost no changes.
yuuji@0 1308 b. Implement separate "x", "t" and "e". Return the "d" right in a
yuuji@0 1309 MYRIGHTS response or an ACL response containing ACL information
yuuji@0 1310 when any of the "t", "e" (and "x") is granted.
yuuji@0 1311
yuuji@0 1312 In a similar manner this document splits the "c" right into several
yuuji@0 1313 new different rights: "k" and possibly "x" (see Section 2.1.1 for
yuuji@0 1314 more details). The "c" right remains for backwards-compatibility but
yuuji@0 1315 it is a virtual right. Again, RFC 2086 server implementors can
yuuji@0 1316 choose to tie rights or to implement separate rights, as described
yuuji@0 1317 above.
yuuji@0 1318
yuuji@0 1319 Also check Sections 5.1.1 and 5.1.2, as well as Appendix A, to see
yuuji@0 1320 other changes required. Server implementors should check which
yuuji@0 1321 rights are required to invoke different IMAP4 commands as described
yuuji@0 1322 in Section 4.
yuuji@0 1323
yuuji@0 1324 Appendix C. Known Deficiencies
yuuji@0 1325
yuuji@0 1326 This specification has some known deficiencies including:
yuuji@0 1327
yuuji@0 1328 1. This is inadequate to provide complete read-write access to
yuuji@0 1329 mailboxes protected by Unix-style rights bits because there is no
yuuji@0 1330 equivalent to "chown" and "chgrp" commands nor is there a good
yuuji@0 1331 way to discover such limitations are present.
yuuji@0 1332 2. Because this extension leaves the specific semantics of how
yuuji@0 1333 rights are combined by the server as implementation defined, the
yuuji@0 1334 ability to build a user-friendly interface is limited.
yuuji@0 1335 3. Users, groups, and special identifiers (e.g., anyone) exist in
yuuji@0 1336 the same namespace.
yuuji@0 1337
yuuji@0 1338 The work-in-progress "ACL2" extension is intended to redesign this
yuuji@0 1339 extension to address these deficiencies without the constraint of
yuuji@0 1340 backward-compatibility and may eventually supercede this facility.
yuuji@0 1341
yuuji@0 1342
yuuji@0 1343
yuuji@0 1344
yuuji@0 1345
yuuji@0 1346 Melnikov Standards Track [Page 24]
yuuji@0 1347
yuuji@0 1348 RFC 4314 IMAP ACL December 2005
yuuji@0 1349
yuuji@0 1350
yuuji@0 1351 However, RFC 2086 is deployed in multiple implementations so this
yuuji@0 1352 intermediate step, which fixes the straightforward deficiencies in a
yuuji@0 1353 backward-compatible fashion, is considered worthwhile.
yuuji@0 1354
yuuji@0 1355 Appendix D. Acknowledgements
yuuji@0 1356
yuuji@0 1357 This document is a revision of RFC 2086 written by John G. Myers.
yuuji@0 1358
yuuji@0 1359 Editor appreciates comments received from Mark Crispin, Chris Newman,
yuuji@0 1360 Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole,
yuuji@0 1361 Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie
yuuji@0 1362 Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon
yuuji@0 1363 Nerenberg, Lisa Dusseault, Arnt Gulbrandsen, and other participants
yuuji@0 1364 of the IMAPEXT working group.
yuuji@0 1365
yuuji@0 1366 Normative References
yuuji@0 1367
yuuji@0 1368 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 1369 Requirement Levels", BCP 14, RFC 2119, March 1997.
yuuji@0 1370
yuuji@0 1371 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
yuuji@0 1372 Specifications: ABNF", RFC 4234, October 2005.
yuuji@0 1373
yuuji@0 1374 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
yuuji@0 1375 4rev1", RFC 3501, March 2003.
yuuji@0 1376
yuuji@0 1377 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
yuuji@0 1378 10646", STD 63, RFC 3629, November 2003.
yuuji@0 1379
yuuji@0 1380 [Stringprep] Hoffman, P. and M. Blanchet, "Preparation of
yuuji@0 1381 Internationalized Strings ("stringprep")", RFC 3454,
yuuji@0 1382 December 2002.
yuuji@0 1383
yuuji@0 1384 [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
yuuji@0 1385 Names and Passwords", RFC 4013, February 2005.
yuuji@0 1386
yuuji@0 1387 Informative References
yuuji@0 1388
yuuji@0 1389 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086,
yuuji@0 1390 January 1997.
yuuji@0 1391
yuuji@0 1392 [PR29] "Public Review Issue #29: Normalization Issue",
yuuji@0 1393 February 2004,
yuuji@0 1394 <http://www.unicode.org/review/pr-29.html>.
yuuji@0 1395
yuuji@0 1396
yuuji@0 1397
yuuji@0 1398
yuuji@0 1399
yuuji@0 1400
yuuji@0 1401
yuuji@0 1402 Melnikov Standards Track [Page 25]
yuuji@0 1403
yuuji@0 1404 RFC 4314 IMAP ACL December 2005
yuuji@0 1405
yuuji@0 1406
yuuji@0 1407 Author's Address
yuuji@0 1408
yuuji@0 1409 Alexey Melnikov
yuuji@0 1410 Isode Ltd.
yuuji@0 1411 5 Castle Business Village
yuuji@0 1412 36 Station Road
yuuji@0 1413 Hampton, Middlesex TW12 2BX
yuuji@0 1414 GB
yuuji@0 1415
yuuji@0 1416 EMail: alexey.melnikov@isode.com
yuuji@0 1417
yuuji@0 1418
yuuji@0 1419
yuuji@0 1420
yuuji@0 1421
yuuji@0 1422
yuuji@0 1423
yuuji@0 1424
yuuji@0 1425
yuuji@0 1426
yuuji@0 1427
yuuji@0 1428
yuuji@0 1429
yuuji@0 1430
yuuji@0 1431
yuuji@0 1432
yuuji@0 1433
yuuji@0 1434
yuuji@0 1435
yuuji@0 1436
yuuji@0 1437
yuuji@0 1438
yuuji@0 1439
yuuji@0 1440
yuuji@0 1441
yuuji@0 1442
yuuji@0 1443
yuuji@0 1444
yuuji@0 1445
yuuji@0 1446
yuuji@0 1447
yuuji@0 1448
yuuji@0 1449
yuuji@0 1450
yuuji@0 1451
yuuji@0 1452
yuuji@0 1453
yuuji@0 1454
yuuji@0 1455
yuuji@0 1456
yuuji@0 1457
yuuji@0 1458 Melnikov Standards Track [Page 26]
yuuji@0 1459
yuuji@0 1460 RFC 4314 IMAP ACL December 2005
yuuji@0 1461
yuuji@0 1462
yuuji@0 1463 Full Copyright Statement
yuuji@0 1464
yuuji@0 1465 Copyright (C) The Internet Society (2005).
yuuji@0 1466
yuuji@0 1467 This document is subject to the rights, licenses and restrictions
yuuji@0 1468 contained in BCP 78, and except as set forth therein, the authors
yuuji@0 1469 retain all their rights.
yuuji@0 1470
yuuji@0 1471 This document and the information contained herein are provided on an
yuuji@0 1472 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
yuuji@0 1473 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
yuuji@0 1474 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
yuuji@0 1475 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
yuuji@0 1476 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
yuuji@0 1477 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 1478
yuuji@0 1479 Intellectual Property
yuuji@0 1480
yuuji@0 1481 The IETF takes no position regarding the validity or scope of any
yuuji@0 1482 Intellectual Property Rights or other rights that might be claimed to
yuuji@0 1483 pertain to the implementation or use of the technology described in
yuuji@0 1484 this document or the extent to which any license under such rights
yuuji@0 1485 might or might not be available; nor does it represent that it has
yuuji@0 1486 made any independent effort to identify any such rights. Information
yuuji@0 1487 on the procedures with respect to rights in RFC documents can be
yuuji@0 1488 found in BCP 78 and BCP 79.
yuuji@0 1489
yuuji@0 1490 Copies of IPR disclosures made to the IETF Secretariat and any
yuuji@0 1491 assurances of licenses to be made available, or the result of an
yuuji@0 1492 attempt made to obtain a general license or permission for the use of
yuuji@0 1493 such proprietary rights by implementers or users of this
yuuji@0 1494 specification can be obtained from the IETF on-line IPR repository at
yuuji@0 1495 http://www.ietf.org/ipr.
yuuji@0 1496
yuuji@0 1497 The IETF invites any interested party to bring to its attention any
yuuji@0 1498 copyrights, patents or patent applications, or other proprietary
yuuji@0 1499 rights that may cover technology that may be required to implement
yuuji@0 1500 this standard. Please address the information to the IETF at ietf-
yuuji@0 1501 ipr@ietf.org.
yuuji@0 1502
yuuji@0 1503 Acknowledgement
yuuji@0 1504
yuuji@0 1505 Funding for the RFC Editor function is currently provided by the
yuuji@0 1506 Internet Society.
yuuji@0 1507
yuuji@0 1508
yuuji@0 1509
yuuji@0 1510
yuuji@0 1511
yuuji@0 1512
yuuji@0 1513
yuuji@0 1514 Melnikov Standards Track [Page 27]
yuuji@0 1515

UW-IMAP'd extensions by yuuji