rfc4314.txt

广泛使用的邮件服务器！同时

Network Working Group                                        A. Melnikov
Request for Comments: 4314                                    Isode Ltd.
Obsoletes: 2086                                            December 2005
Category: Standards Track


               IMAP4 Access Control List (ACL) Extension

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The Access Control List (ACL) extension (RFC 2086) of the Internet
   Message Access Protocol (IMAP) permits mailbox access control lists
   to be retrieved and manipulated through the IMAP protocol.

   This document is a revision of RFC 2086.  It defines several new
   access control rights and clarifies which rights are required for
   different IMAP commands.






















Melnikov                    Standards Track                     [Page 1]

RFC 4314                        IMAP ACL                   December 2005


Table of Contents

   1. Introduction and Overview .......................................3
      1.1. Conventions Used in This Document ..........................3
   2. Access Control ..................................................3
      2.1. Standard Rights ............................................5
           2.1.1. Obsolete Rights .....................................5
      2.2. Rights Defined in RFC 2086 .................................8
   3. Access control management commands and responses ................8
      3.1. SETACL Command .............................................8
      3.2. DELETEACL Command ..........................................9
      3.3. GETACL Command ............................................10
      3.4. LISTRIGHTS Command ........................................10
      3.5. MYRIGHTS Command ..........................................11
      3.6. ACL Response ..............................................11
      3.7. LISTRIGHTS Response .......................................12
      3.8. MYRIGHTS Response .........................................12
   4. Rights Required to Perform Different IMAP4rev1 Commands ........12
   5. Other Considerations ...........................................17
      5.1. Additional Requirements and Implementation Notes ..........17
           5.1.1. Servers ............................................17
           5.1.2. Clients ............................................18
      5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY
           Response Codes ............................................19
   6. Security Considerations ........................................20
   7. Formal Syntax ..................................................21
   8. IANA Considerations ............................................22
   9. Internationalization Considerations ............................22
   Appendix A. Changes since RFC 2086 ................................23
   Appendix B. Compatibility with RFC 2086 ...........................24
   Appendix C. Known Deficiencies ....................................24
   Appendix D. Acknowledgements ......................................25
   Normative References ..............................................25
   Informative References ............................................25

















Melnikov                    Standards Track                     [Page 2]

RFC 4314                        IMAP ACL                   December 2005


1.  Introduction and Overview

   The ACL (Access Control List) extension of the Internet Message
   Access Protocol [IMAP4] permits mailbox access control lists to be
   retrieved and manipulated through the IMAP protocol.

   This document is a revision of RFC 2086 [RFC2086].  It tries to
   clarify different ambiguities in RFC 2086, in particular, the use of
   UTF-8 [UTF-8] in access identifiers, which rights are required for
   different IMAP4 commands, and how READ-WRITE/READ-ONLY response codes
   are related to ACL.

1.1.  Conventions Used in This Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   In all examples "/" character is used as hierarchy separator.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

   The phrase "ACL server" is just a shortcut for saying "IMAP server
   that supports ACL extension as defined in this document".

2.  Access Control

   The ACL extension is present in any IMAP4 implementation that returns
   "ACL" as one of the supported capabilities to the CAPABILITY command.

   A server implementation conformant to this document MUST also return
   rights (see below) not defined in Section 2.2 in the "RIGHTS="
   capability.

   An access control list is a set of <access identifier,rights> pairs.
   An ACL applies to a mailbox name.

   Access identifier (or just "identifier") is a UTF-8 [UTF-8] string.
   The identifier "anyone" is reserved to refer to the universal
   identity (all authentications, including anonymous).  All user name
   strings accepted by the LOGIN or AUTHENTICATE commands to
   authenticate to the IMAP server are reserved as identifiers for the
   corresponding users.  Identifiers starting with a dash ("-") are
   reserved for "negative rights", described below.  All other
   identifier strings are interpreted in an implementation-defined
   manner.




Melnikov                    Standards Track                     [Page 3]

RFC 4314                        IMAP ACL                   December 2005


   Rights is a string listing a (possibly empty) set of alphanumeric
   characters, each character listing a set of operations that is being
   controlled.  Lowercase letters are reserved for "standard" rights,
   listed in Section 2.1.  (Note that for compatibility with deployed
   clients and servers uppercase rights are not allowed.)  The set of
   standard rights can only be extended by a standards-track document.
   Digits are reserved for implementation- or site-defined rights.

   An implementation MAY tie rights together or MAY force rights to
   always or never be granted to particular identifiers.  For example,
   in an implementation that uses UNIX mode bits, the rights "swite" are
   tied, the "a" right is always granted to the owner of a mailbox and
   is never granted to another user.  If rights are tied in an
   implementation, the implementation must be conservative in granting
   rights in response to SETACL commands--unless all rights in a tied
   set are specified, none of that set should be included in the ACL
   entry for that identifier.  A client can discover the set of rights
   that may be granted to a given identifier in the ACL for a given
   mailbox name by using the LISTRIGHTS command.

   It is possible for multiple identifiers in an access control list to
   apply to a given user.  For example, an ACL may include rights to be
   granted to the identifier matching the user, one or more
   implementation-defined identifiers matching groups that include the
   user, and/or the identifier "anyone".  How these rights are combined
   to determine the user's access is implementation defined.  An
   implementation may choose, for example, to use the union of the
   rights granted to the applicable identifiers.  An implementation may
   instead choose, for example, to use only those rights granted to the
   most specific identifier present in the ACL.  A client can determine
   the set of rights granted to the logged-in user for a given mailbox
   name by using the MYRIGHTS command.

   When an identifier in an ACL starts with a dash ("-"), that indicates
   that associated rights are to be removed from the identifier prefixed
   by the dash.  This is referred to as a "negative right".  This
   differs from DELETEACL in that a negative right is added to the ACL
   and is a part of the calculation of the rights.

   Let's assume that an identifier "fred" refers to a user with login
   "fred".  If the identifier "-fred" is granted the "w" right, that
   indicates that the "w" right is to be removed from users matching the
   identifier "fred", even though the user "fred" might have the "w"
   right as a consequence of some other identifier in the ACL.  A
   DELETEACL of "fred" simply deletes the identifier "fred" from the
   ACL; it does not affect any rights that the user "fred" may get from
   another entry in the ACL, in particular it doesn't affect rights
   granted to the identifier "-fred".



Melnikov                    Standards Track                     [Page 4]

RFC 4314                        IMAP ACL                   December 2005


   Server implementations are not required to support "negative right"
   identifiers.

2.1.  Standard Rights

   The currently defined standard rights are (note that the list below
   doesn't list all commands that use a particular right):

   l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE
       mailbox)
   r - read (SELECT the mailbox, perform STATUS)
   s - keep seen/unseen information across sessions (set or clear
       \SEEN flag via STORE, also set \SEEN during APPEND/COPY/
       FETCH BODY[...])
   w - write (set or clear flags other than \SEEN and \DELETED via
       STORE, also set them during APPEND/COPY)
   i - insert (perform APPEND, COPY into mailbox)
   p - post (send mail to submission address for mailbox,
       not enforced by IMAP4 itself)
   k - create mailboxes (CREATE new sub-mailboxes in any
       implementation-defined hierarchy, parent mailbox for the new
       mailbox name in RENAME)
   x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
   t - delete messages (set or clear \DELETED flag via STORE, set
       \DELETED flag during APPEND/COPY)
   e - perform EXPUNGE and expunge as a part of CLOSE
   a - administer (perform SETACL/DELETEACL/GETACL/LISTRIGHTS)

2.1.1.  Obsolete Rights

   Due to ambiguity in RFC 2086, some existing RFC 2086 server
   implementations use the "c" right to control the DELETE command.
   Others chose to use the "d" right to control the DELETE command.  For
   the former group, let's define the "create" right as union of the "k"
   and "x" rights, and the "delete" right as union of the "e" and "t"
   rights.  For the latter group, let's define the "create" rights as a
   synonym to the "k" right, and the "delete" right as union of the "e",
   "t", and "x" rights.

   For compatibility with RFC 2086, this section defines two virtual
   rights "d" and "c".

   If a client includes the "d" right in a rights list, then it MUST be
   treated as if the client had included every member of the "delete"
   right.  (It is not an error for a client to specify both the "d"
   right and one or more members of the "delete" right, but the effect
   is no different than if just the "d" right or all members of the
   "delete" right had been specified.)



Melnikov                    Standards Track                     [Page 5]

RFC 4314                        IMAP ACL                   December 2005


   When any of the "delete" member rights is set in a list of rights,
   the server MUST also include the "d" right when returning the list in
   a MYRIGHTS or ACL response.  This is to enable older clients
   conforming to RFC 2086 to work with newer servers. (*)

   Example:    C: A001 SeTacl INBOX/Drafts David lrswida
               S: A001 OK Setacl complete

   The client has specified the "d" right in the SETACL command above
   and it expands to "et" on the server:

               C: A002 getacl INBOX/Drafts
               S: * ACL INBOX Fred rwipslxcetda David lrswideta
               S: A002 OK Getacl complete

   If the identifier specified in the LISTRIGHTS command can be granted
   any of the "delete" member rights on a mailbox, then the server MUST
   include the "d" right in the corresponding LISTRIGHTS response. (*)
   If the member rights aren't tied to non-member rights, then the "d"
   right is returned by itself in the LISTRIGHTS response.  If any of
   the member rights needs to be tied to one (or more) non-member right,
   then the "d" right and all of the member rights need to be tied to
   the same non-member right(s) (**).

   If a client includes the "c" right in a rights list, then it MUST be
   treated as if the client had included every member of the "create"
   right.  (It is not an error for a client to specify both the "c"
   right and one or more members of the "create" right, but the effect
   is no different than if just the "c" right or all members of the
   "create" right had been specified.)

   When any of the "create" member rights is set in a list of rights,
   the server MUST also include the "c" right when returning the list in
   a MYRIGHTS or ACL response.  This is to enable older clients
   conforming to RFC 2086 to work with newer servers. (*)

   Example:    C: A003 Setacl INBOX/Drafts Byron lrswikda
               S: A001 OK Setacl complete
               C: A002 getAcl INBOX/Drafts
               S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
               S: A002 OK Getacl complete

   The client has specified the "d" right in the SETACL command above
   and it expands to "et" on the server: As the client has specified the
   "k" right (which is a member of the "c" right), the server also
   returns the "c" right.





Melnikov                    Standards Track                     [Page 6]

RFC 4314                        IMAP ACL                   December 2005


   If the identifier specified in the LISTRIGHTS command can be granted
   any of the "create" member rights on a mailbox, then the server MUST
   include the "c" right in the corresponding LISTRIGHTS response. (*)
   If the member rights aren't tied to non-member rights, then the "c"
   right is returned by itself in the LISTRIGHTS response.  If any of
   the member rights needs to be tied to one (or more) non-member right,
   then the "c" right and all of the member rights need to be tied to
   the same non-member right(s) (**).

   Example: The server that ties the rights as follows:

               lr s w i p k x t

            and c=k

            will return:

               S: * LISTRIGHTS archive/imap anyone ""
                  lr s w i p k x t c d

   Example: The server that ties the rights as follows:

               lr s w i p k xte

            and c=k

            will return:

               S: * LISTRIGHTS archive/imap anyone ""
                  lr s w i p k xte c d

   Example: The server that ties the rights as follows:

               lr s w i p k x te

            and c=k