Skip to content

John McEleney / mailutils

Go to a project
Toggle navigation
Toggle navigation pinning
Commit 7bbd113a 7bbd113abecfa1c5eb0be421c7ab5c8b0e5ce759 by Sergey Poznyakoff
Options

Add rfc4314.txt

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