rfc4314.txt

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

   Mailbox management:
      CREATE - "k" right on a nearest existing parent mailbox.  When a
      new mailbox is created, it SHOULD inherit the ACL from the parent
      mailbox (if one exists) in the defined hierarchy.

      DELETE - "x" right on the mailbox.  Note that some servers don't
      allow to delete a non-empty mailbox.  If this is the case, the
      user would also need "r", "e", and "t" rights, in order to open
      the mailbox and empty it.

      The DELETE command MUST delete the ACL associated with the deleted
      mailbox.

      RENAME - Moving a mailbox from one parent to another requires the
      "x" right on the mailbox itself and the "k" right for the new
      parent.  For example, if the user wants to rename the mailbox
      named "A/B/C" to "D/E", the user must have the "x" right for the
      mailbox "A/B/C" and the "k" right for the mailbox "D".
      The RENAME command SHOULD NOT change the ACLs on the renamed
      mailbox and submailboxes.






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


   Copying or appending messages:
      Before performing a COPY/APPEND command, the server MUST check if
      the user has "i" right for the target mailbox.  If the user
      doesn't have "i" right, the operation fails.  Otherwise for each
      copied/appended message the server MUST check if the user has
         "t" right - when the message has \Deleted flag set
         "s" right - when the message has \Seen flag set
         "w" right - for all other message flags.
      Only when the user has a particular right are the corresponding
      flags stored for the newly created message.  The server MUST NOT
      fail a COPY/APPEND if the user has no rights to set a particular
      flag.

   Example:    C: A003 MYRIGHTS TargetMailbox
               S: * MYRIGHTS TargetMailbox rwis
               S: A003 OK Myrights complete

               C: A004 FETCH 1:3 (FLAGS)
               S: * 1 FETCH (FLAGS (\Draft \Deleted)
               S: * 2 FETCH (FLAGS (\Answered)
               S: * 3 FETCH (FLAGS ($Forwarded \Seen)
               S: A004 OK Fetch Completed

               C: A005 COPY 1:3 TargetMailbox
               S: A005 OK Copy completed

               C: A006 SELECT TargetMailbox
                  ...
               S: A006 Select Completed

      Let's assume that the copied messages received message numbers
      77:79.

               C: A007 FETCH 77:79 (FLAGS)
               S: * 77 FETCH (FLAGS (\Draft))
               S: * 78 FETCH (FLAGS (\Answered))
               S: * 79 FETCH (FLAGS ($Forwarded \Seen))
               S: A007 OK Fetch Completed

      \Deleted flag was lost on COPY, as the user has no "t" right in
      the target mailbox.
      If the MYRIGHTS command with the tag A003 would have returned:

               S: * MYRIGHTS TargetMailbox rsti

      the response from the FETCH with the tag A007 would have been:

               C: A007 FETCH 77:79 (FLAGS)



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


               S: * 77 FETCH (FLAGS (\Deleted))
               S: * 78 FETCH (FLAGS ())
               S: * 79 FETCH (FLAGS (\Seen))
               S: A007 OK Fetch Completed

      In the latter case, \Answered, $Forwarded, and \Draft flags were
      lost on COPY, as the user has no "w" right in the target mailbox.

   Expunging the selected mailbox:
      EXPUNGE - "e" right on the selected mailbox.

      CLOSE - "e" right on the selected mailbox.  If the server is
      unable to expunge the mailbox because the user doesn't have the
      "e" right, the server MUST ignore the expunge request, close the
      mailbox, and return the tagged OK response.

   Fetch information about a mailbox and its messages:
      SELECT/EXAMINE/STATUS - "r" right on the mailbox.

      FETCH - A FETCH request that implies setting \Seen flag MUST NOT
      set it, if the current user doesn't have "s" right.

   Changing flags:
      STORE - the server MUST check if the user has
         "t" right - when the user modifies \Deleted flag
         "s" right - when the user modifies \Seen flag
         "w" right - for all other message flags.
      STORE operation SHOULD NOT fail if the user has rights to modify
      at least one flag specified in the STORE, as the tagged NO
      response to a STORE command is not handled very well by deployed
      clients.

   Changing ACLs:
      SETACL/DELETEACL - "a" right on the mailbox.

   Reading ACLs:
      GETACL - "a" right on the mailbox.

      MYRIGHTS - any of the following rights is required to perform the
      operation: "l", "r", "i", "k", "x", "a".

      LISTRIGHTS - "a" right on the mailbox.









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


5.  Other Considerations

5.1.  Additional Requirements and Implementation Notes

5.1.1.  Servers

   This document defines an additional capability that is used to
   announce the list of extra rights (excluding the ones defined in RFC
   2086) supported by the server.  The set of rights MUST include "t",
   "e", "x", and "k".  Note that the extra rights can appear in any
   order.

   Example:    C: 1 capability
               S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+
                  ACL RIGHTS=texk
               S: 1 OK completed

   Any server implementing an ACL extension MUST accurately reflect the
   current user's rights in FLAGS and PERMANENTFLAGS responses.

   Example:    C: A142 SELECT INBOX
               S: * 172 EXISTS
               S: * 1 RECENT
               S: * OK [UNSEEN 12] Message 12 is first unseen
               S: * OK [UIDVALIDITY 3857529045] UIDs valid
               S: * OK [UIDNEXT 4392] Predicted next UID
               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
               S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
               S: A142 OK [READ-WRITE] SELECT completed
               C: A143 MYRIGHTS INBOX
               S: * MYRIGHTS INBOX lrwis
               S: A143 OK completed

   Note that in order to get better performance the client MAY pipeline
   SELECT and MYRIGHTS commands:

               C: A142 SELECT INBOX
               C: A143 MYRIGHTS INBOX
               S: * 172 EXISTS
               S: * 1 RECENT
               S: * OK [UNSEEN 12] Message 12 is first unseen
               S: * OK [UIDVALIDITY 3857529045] UIDs valid
               S: * OK [UIDNEXT 4392] Predicted next UID
               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
               S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
               S: A142 OK [READ-WRITE] SELECT completed
               S: * MYRIGHTS INBOX lrwis
               S: A143 OK completed



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


   Servers MAY cache the rights a user has on a mailbox when the mailbox
   is selected, so that if a client's rights on a mailbox are changed
   with SETACL or DELETEACL, commands specific to the selected state
   (e.g., STORE, EXPUNGE) might not reflect the changed rights until the
   mailbox is re-selected.  If the server checks the rights on each
   command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if
   they have changed.  If such server detects that the user no longer
   has read access to the mailbox, it MAY send an untagged BYE response
   and close connection.  It MAY also refuse to execute all commands
   specific to the selected state until the mailbox is closed; however,
   server implementors should note that most clients don't handle NO
   responses very well.

   An ACL server MAY modify one or more ACLs for one or more identifiers
   as a side effect of modifying the ACL specified in a
   SETACL/DELETEACL.  If the server does that, it MUST send untagged ACL
   response(s) to notify the client about the changes made.

   An ACL server implementation MUST treat received ACL modification
   commands as a possible ambiguity with respect to subsequent commands
   affected by the ACL, as described in Section 5.5 of [IMAP4].  Hence a
   pipeline SETACL + MYRIGHTS is an ambiguity with respect to the
   server, meaning that the server must execute the SETACL command to
   completion before the MYRIGHTS.  However, clients are permitted to
   send such a pipeline.

5.1.2.  Clients

   The following requirement is put on clients in order to allow for
   future extensibility.  A client implementation that allows a user to
   read and update ACLs MUST preserve unrecognized rights that it
   doesn't allow the user to change.  That is, if the client

   1) can read ACLs
    and
   2) can update ACLs
    but
   3) doesn't allow the user to change the rights the client doesn't
   recognize, then it MUST preserve unrecognized rights.

   Otherwise the client could risk unintentionally removing permissions
   it doesn't understand.









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


5.2.  Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes

   A particular ACL server implementation MAY allow "shared multiuser
   access" to some mailboxes.  "Shared multiuser access" to a mailbox
   means that multiple different users are able to access the same
   mailbox, if they have proper access rights.  "Shared multiuser
   access" to the mailbox doesn't mean that the ACL for the mailbox is
   currently set to allow access by multiple users.  Let's denote a
   "shared multiuser write access" as a "shared multiuser access" when a
   user can be granted flag modification rights (any of "w", "s", or
   "t").

   Section 4 describes which rights are required for modifying different
   flags.

   If the ACL server implements some flags as shared for a mailbox
   (i.e., the ACL for the mailbox MAY be set up so that changes to those
   flags are visible to another user), let's call the set of rights
   associated with these flags (as described in Section 4) for that
   mailbox collectively as "shared flag rights".  Note that the "shared
   flag rights" set MAY be different for different mailboxes.

   If the server doesn't support "shared multiuser write access" to a
   mailbox or doesn't implement shared flags on the mailbox, "shared
   flag rights" for the mailbox is defined to be the empty set.

   Example 1: Mailbox "banan" allows "shared multiuser write access" and
              implements flags \Deleted, \Answered, and $MDNSent as
              shared flags. "Shared flag rights" for the mailbox "banan"
              is a set containing flags "t" (because system flag
              \Deleted requires "t" right) and "w" (because both
              \Answered and $MDNSent require "w" right).

   Example 2: Mailbox "apple" allows "shared multiuser write access" and
              implements \Seen system flag as shared flag. "Shared flag
              rights" for the mailbox "apple" contains "s" right
              because system flag \Seen requires "s" right.

   Example 3: Mailbox "pear" allows "shared multiuser write access" and
              implements flags \Seen, \Draft as shared flags. "Shared
              flag rights" for the mailbox "apple" is a set containing
              flags "s" (because system flag \Seen requires "s" right)
              and "w" (because system flag \Draft requires "w" right).

   The server MUST include a READ-ONLY response code in the tagged OK
   response to a SELECT command if none of the following rights is
   granted to the current user:




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


    "i", "e", and "shared flag rights"(***).

   The server SHOULD include a READ-WRITE response code in the tagged OK
   response if at least one of the "i", "e", or "shared flag
   rights"(***) is granted to the current user.

   (***) Note that a future extension to this document can extend the
   list of rights that causes the server to return the READ-WRITE
   response code.

   Example 1 (continued): The user that has "lrs" rights for the mailbox
                          "banan".  The server returns READ-ONLY
                          response code on SELECT, as none of "iewt"
                          rights is granted to the user.

   Example 2 (continued): The user that has "rit" rights for the mailbox
                          "apple".  The server returns READ-WRITE
                          response code on SELECT, as the user has "i"
                          right.

   Example 3 (continued): The user that has "rset" rights for the
                          mailbox "pear".  The server returns READ-WRITE
                          response code on SELECT, as the user has "e"
                          and "s" rights.

6.  Security Considerations

   An implementation MUST make sure the ACL commands themselves do not
   give information about mailboxes with appropriately restricted ACLs.
   For example, when a user agent executes a GETACL command on a mailbox
   that the user has no permission to LIST, the server would respond to
   that request with the same error that would be used if the mailbox
   did not exist, thus revealing no existence information, much less the
   mailbox's ACL.

   IMAP clients implementing ACL that are able to modify ACLs SHOULD
   warn a user that wants to give full access (or even just the "a"
   right) to the special identifier "anyone".

   This document relies on [SASLprep] to describe steps required to
   perform identifier canonicalization (preparation).  The preparation
   algorithm in SASLprep was specifically designed such that its output
   is canonical, and it is well-formed.  However, due to an anomaly
   [PR29] in the specification of Unicode normalization, canonical
   equivalence is not guaranteed for a select few character sequences.
   Identifiers prepared with SASLprep can be stored and returned by an
   ACL server.  The anomaly affects ACL manipulation and evaluation of
   identifiers containing the selected character sequences.  These



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


   sequences, however, do not appear in well-formed text.  In order to
   address this problem, an ACL server MAY reject identifiers containing
   sequences described in [PR29] by sending the tagged BAD response.
   This is in addition to the requirement to reject identifiers that
   fail SASLprep preparation as described in Section 3.

   Other security considerations described in [IMAP4] are relevant to
   this document.  In particular, ACL information is sent in the clear
   over the network unless confidentiality protection is negotiated.

   This can be accomplished either by the use of STARTTLS, negotiated