7Network Working Group A. Melnikov
8Request for Comments: 4314 Isode Ltd.
9Obsoletes: 2086 December 2005
10Category: Standards Track
13 IMAP4 Access Control List (ACL) Extension
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.
25 Copyright (C) The Internet Society (2005).
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.
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.
58Melnikov Standards Track [Page 1]
60RFC 4314 IMAP ACL December 2005
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
114Melnikov Standards Track [Page 2]
116RFC 4314 IMAP ACL December 2005
1191. Introduction and Overview
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.
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
1311.1. Conventions Used in This Document
133 In examples, "C:" and "S:" indicate lines sent by the client and
136 In all examples "/" character is used as hierarchy separator.
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].
142 The phrase "ACL server" is just a shortcut for saying "IMAP server
143 that supports ACL extension as defined in this document".
147 The ACL extension is present in any IMAP4 implementation that returns
148 "ACL" as one of the supported capabilities to the CAPABILITY command.
150 A server implementation conformant to this document MUST also return
151 rights (see below) not defined in Section 2.2 in the "RIGHTS="
154 An access control list is a set of <access identifier,rights> pairs.
155 An ACL applies to a mailbox name.
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
170Melnikov Standards Track [Page 3]
172RFC 4314 IMAP ACL December 2005
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.
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.
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.
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.
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".
226Melnikov Standards Track [Page 4]
228RFC 4314 IMAP ACL December 2005
231 Server implementations are not required to support "negative right"
236 The currently defined standard rights are (note that the list below
237 doesn't list all commands that use a particular right):
239 l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE
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/
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)
2592.1.1. Obsolete Rights
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",
270 For compatibility with RFC 2086, this section defines two virtual
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.)
282Melnikov Standards Track [Page 5]
284RFC 4314 IMAP ACL December 2005
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. (*)
292 Example: C: A001 SeTacl INBOX/Drafts David lrswida
293 S: A001 OK Setacl complete
295 The client has specified the "d" right in the SETACL command above
296 and it expands to "et" on the server:
298 C: A002 getacl INBOX/Drafts
299 S: * ACL INBOX Fred rwipslxcetda David lrswideta
300 S: A002 OK Getacl complete
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) (**).
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.)
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. (*)
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
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.
338Melnikov Standards Track [Page 6]
340RFC 4314 IMAP ACL December 2005
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) (**).
352 Example: The server that ties the rights as follows:
360 S: * LISTRIGHTS archive/imap anyone ""
363 Example: The server that ties the rights as follows:
371 S: * LISTRIGHTS archive/imap anyone ""
374 Example: The server that ties the rights as follows:
382 S: * LISTRIGHTS archive/imap anyone ""
383 lr s w i p k c x te d
385 Example: The server that ties the rights as follows:
394Melnikov Standards Track [Page 7]
396RFC 4314 IMAP ACL December 2005
401 S: * LISTRIGHTS archive/imap anyone ""
404 (*) Clients conforming to this document MUST ignore the virtual "d"
405 and "c" rights in MYRIGHTS, ACL, and LISTRIGHTS responses.
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.
4112.2. Rights Defined in RFC 2086
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
4173. Access control management commands and responses
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
430 Arguments: mailbox name
432 access right modification
434 Data: no specific data for this command
436 Result: OK - setacl completed
437 NO - setacl failure: can't set acl
438 BAD - arguments invalid
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.
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
450Melnikov Standards Track [Page 8]
452RFC 4314 IMAP ACL December 2005
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.
460 Note that an unrecognized right MUST cause the command to return the
461 BAD response. In particular, the server MUST NOT silently ignore
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
474 C: A035 SETACL INBOX/Drafts John lrQswicda
475 S: A035 BAD Uppercase rights are not allowed
478 C: A036 SETACL INBOX/Drafts John lrqswicda
479 S: A036 BAD The q right is not supported
4813.2. DELETEACL Command
483 Arguments: mailbox name
486 Data: no specific data for this command
488 Result: OK - deleteacl completed
489 NO - deleteacl failure: can't delete acl
490 BAD - arguments invalid
492 The DELETEACL command removes any <identifier,rights> pair for the
493 specified identifier from the access control list for the specified
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
506Melnikov Standards Track [Page 9]
508RFC 4314 IMAP ACL December 2005
512 S: * ACL INBOX -Fred wetd $team w
513 S: B003 OK Getacl complete
517 Arguments: mailbox name
519 Data: untagged responses: ACL
521 Result: OK - getacl completed
522 NO - getacl failure: can't get acl
523 BAD - arguments invalid
525 The GETACL command returns the access control list for mailbox in an
526 untagged ACL response.
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.
535 Example: C: A002 GETACL INBOX
536 S: * ACL INBOX Fred rwipsldexta
537 S: A002 OK Getacl complete
5393.4. LISTRIGHTS Command
541 Arguments: mailbox name
544 Data: untagged responses: LISTRIGHTS
546 Result: OK - listrights completed
547 NO - listrights failure: can't get rights list
548 BAD - arguments invalid
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.
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
562Melnikov Standards Track [Page 10]
564RFC 4314 IMAP ACL December 2005
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.
571 Example: C: a001 LISTRIGHTS ~/Mail/saved smith
572 S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte
573 S: a001 OK Listrights completed
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
582 Arguments: mailbox name
584 Data: untagged responses: MYRIGHTS
586 Result: OK - myrights completed
587 NO - myrights failure: can't get rights
588 BAD - arguments invalid
590 The MYRIGHTS command returns the set of rights that the user has to
591 mailbox in an untagged MYRIGHTS reply.
593 Example: C: A003 MYRIGHTS INBOX
594 S: * MYRIGHTS INBOX rwiptsldaex
595 S: A003 OK Myrights complete
600 zero or more identifier rights pairs
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.
608 Section 2.1.1 details additional server requirements related to
609 handling of the virtual "d" and "c" rights.
618Melnikov Standards Track [Page 11]
620RFC 4314 IMAP ACL December 2005
6233.7. LISTRIGHTS Response
628 list of optional rights
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.
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.
643 The same right MUST NOT be listed more than once in the LISTRIGHTS
6463.8. MYRIGHTS Response
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.
655 Section 2.1.1 details additional server requirements related to
656 handling of the virtual "d" and "c" rights.
6584. Rights Required to Perform Different IMAP4rev1 Commands
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.
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.
674Melnikov Standards Track [Page 12]
676RFC 4314 IMAP ACL December 2005
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
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 +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
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.
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
725 "Non" - No rights required to perform the command
730Melnikov Standards Track [Page 13]
732RFC 4314 IMAP ACL December 2005
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:
744 S: * LIST (\NoInferiors) "/" "A/B"
746 S: * LIST (\NoInferiors) "/" "C/D"
747 S: A777 OK LIST completed
750 SUBSCRIBE - "l" right is required only if the server checks for
751 mailbox existence when performing SUBSCRIBE.
753 UNSUBSCRIBE - no rights required to perform this operation.
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.
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.
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.
770 The DELETE command MUST delete the ACL associated with the deleted
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.
786Melnikov Standards Track [Page 14]
788RFC 4314 IMAP ACL December 2005
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
804 Example: C: A003 MYRIGHTS TargetMailbox
805 S: * MYRIGHTS TargetMailbox rwis
806 S: A003 OK Myrights complete
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
814 C: A005 COPY 1:3 TargetMailbox
815 S: A005 OK Copy completed
817 C: A006 SELECT TargetMailbox
819 S: A006 Select Completed
821 Let's assume that the copied messages received message numbers
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
830 \Deleted flag was lost on COPY, as the user has no "t" right in
832 If the MYRIGHTS command with the tag A003 would have returned:
834 S: * MYRIGHTS TargetMailbox rsti
836 the response from the FETCH with the tag A007 would have been:
838 C: A007 FETCH 77:79 (FLAGS)
842Melnikov Standards Track [Page 15]
844RFC 4314 IMAP ACL December 2005
847 S: * 77 FETCH (FLAGS (\Deleted))
848 S: * 78 FETCH (FLAGS ())
849 S: * 79 FETCH (FLAGS (\Seen))
850 S: A007 OK Fetch Completed
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.
855 Expunging the selected mailbox:
856 EXPUNGE - "e" right on the selected mailbox.
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.
863 Fetch information about a mailbox and its messages:
864 SELECT/EXAMINE/STATUS - "r" right on the mailbox.
866 FETCH - A FETCH request that implies setting \Seen flag MUST NOT
867 set it, if the current user doesn't have "s" right.
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
880 SETACL/DELETEACL - "a" right on the mailbox.
883 GETACL - "a" right on the mailbox.
885 MYRIGHTS - any of the following rights is required to perform the
886 operation: "l", "r", "i", "k", "x", "a".
888 LISTRIGHTS - "a" right on the mailbox.
898Melnikov Standards Track [Page 16]
900RFC 4314 IMAP ACL December 2005
9035. Other Considerations
9055.1. Additional Requirements and Implementation Notes
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
915 Example: C: 1 capability
916 S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+
920 Any server implementing an ACL extension MUST accurately reflect the
921 current user's rights in FLAGS and PERMANENTFLAGS responses.
923 Example: C: A142 SELECT INBOX
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
936 Note that in order to get better performance the client MAY pipeline
937 SELECT and MYRIGHTS commands:
940 C: A143 MYRIGHTS INBOX
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
954Melnikov Standards Track [Page 17]
956RFC 4314 IMAP ACL December 2005
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
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.
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.
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
996 3) doesn't allow the user to change the rights the client doesn't
997 recognize, then it MUST preserve unrecognized rights.
999 Otherwise the client could risk unintentionally removing permissions
1000 it doesn't understand.
1010Melnikov Standards Track [Page 18]
1012RFC 4314 IMAP ACL December 2005
10155.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes
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
1027 Section 4 describes which rights are required for modifying different
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.
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.
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).
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.
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).
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:
1066Melnikov Standards Track [Page 19]
1068RFC 4314 IMAP ACL December 2005
1071 "i", "e", and "shared flag rights"(***).
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.
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
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.
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"
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"
10966. Security Considerations
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
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".
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
1122Melnikov Standards Track [Page 20]
1124RFC 4314 IMAP ACL December 2005
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.
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.
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.
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
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.
1152 LOWER-ALPHA = %x61-7A ;; a-z
1154 acl-data = "ACL" SP mailbox *(SP identifier SP
1157 capability =/ rights-capa
1158 ;;capability is defined in [IMAP4]
1160 command-auth =/ setacl / deleteacl / getacl /
1161 listrights / myrights
1162 ;;command-auth is defined in [IMAP4]
1164 deleteacl = "DELETEACL" SP mailbox SP identifier
1166 getacl = "GETACL" SP mailbox
1168 identifier = astring
1170 listrights = "LISTRIGHTS" SP mailbox SP identifier
1172 listrights-data = "LISTRIGHTS" SP mailbox SP identifier
1173 SP rights *(SP rights)
1178Melnikov Standards Track [Page 21]
1180RFC 4314 IMAP ACL December 2005
1183 mailbox-data =/ acl-data / listrights-data / myrights-data
1184 ;;mailbox-data is defined in [IMAP4]
1186 mod-rights = astring
1187 ;; +rights to add, -rights to remove
1188 ;; rights to replace
1190 myrights = "MYRIGHTS" SP mailbox
1192 myrights-data = "MYRIGHTS" SP mailbox SP rights
1194 new-rights = 1*LOWER-ALPHA
1195 ;; MUST include "t", "e", "x", and "k".
1196 ;; MUST NOT include standard rights listed
1200 ;; only lowercase ASCII letters and digits
1203 rights-capa = "RIGHTS=" new-rights
1204 ;; RIGHTS=... capability
1206 setacl = "SETACL" SP mailbox SP identifier
12098. IANA Considerations
1211 IMAP4 capabilities are registered by publishing a standards-track or
1212 IESG-approved experimental RFC. The registry is currently located
1215 http://www.iana.org/assignments/imap4-capabilities
1217 This document defines the RIGHTS= IMAP capability. IANA has added
1218 this capability to the registry.
12209. Internationalization Considerations
1222 Section 3 states requirements on servers regarding
1223 internationalization of identifiers.
1234Melnikov Standards Track [Page 22]
1236RFC 4314 IMAP ACL December 2005
1239Appendix A. Changes since RFC 2086
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
1253 8. LISTRIGHTS requires the "a" right on the mailbox (same as
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
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.
1290Melnikov Standards Track [Page 23]
1292RFC 4314 IMAP ACL December 2005
1295Appendix B. Compatibility with RFC 2086
1297 This non-normative section gives guidelines as to how an existing RFC
1298 2086 server implementation may be updated to comply with this
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:
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.
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
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
1324Appendix C. Known Deficiencies
1326 This specification has some known deficiencies including:
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
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.
1346Melnikov Standards Track [Page 24]
1348RFC 4314 IMAP ACL December 2005
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.
1355Appendix D. Acknowledgements
1357 This document is a revision of RFC 2086 written by John G. Myers.
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.
1368 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
1369 Requirement Levels", BCP 14, RFC 2119, March 1997.
1371 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1372 Specifications: ABNF", RFC 4234, October 2005.
1374 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
1375 4rev1", RFC 3501, March 2003.
1377 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
1378 10646", STD 63, RFC 3629, November 2003.
1380 [Stringprep] Hoffman, P. and M. Blanchet, "Preparation of
1381 Internationalized Strings ("stringprep")", RFC 3454,
1384 [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
1385 Names and Passwords", RFC 4013, February 2005.
1387Informative References
1389 [RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086,
1392 [PR29] "Public Review Issue #29: Normalization Issue",
1394 <http://www.unicode.org/review/pr-29.html>.
1402Melnikov Standards Track [Page 25]
1404RFC 4314 IMAP ACL December 2005
1411 5 Castle Business Village
1413 Hampton, Middlesex TW12 2BX
1416 EMail: alexey.melnikov@isode.com
1458Melnikov Standards Track [Page 26]
1460RFC 4314 IMAP ACL December 2005
1463Full Copyright Statement
1465 Copyright (C) The Internet Society (2005).
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.
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.
1479Intellectual Property
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.
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.
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-
1505 Funding for the RFC Editor function is currently provided by the
1514Melnikov Standards Track [Page 27]