rfc4314.txt

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

   privacy protection in the AUTHENTICATE command, or some other
   protection mechanism.

7.  Formal Syntax

   Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
   in Section 9 of [IMAP4].  Elements not defined here can be found in
   [ABNF] and [IMAP4].

   Except as noted otherwise, all alphabetic characters are case
   insensitive.  The use of uppercase or lowercase characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

   LOWER-ALPHA     =  %x61-7A   ;; a-z

   acl-data        = "ACL" SP mailbox *(SP identifier SP
                       rights)

   capability      =/ rights-capa
                       ;;capability is defined in [IMAP4]

   command-auth    =/ setacl / deleteacl / getacl /
                       listrights / myrights
                       ;;command-auth is defined in [IMAP4]

   deleteacl       = "DELETEACL" SP mailbox SP identifier

   getacl          = "GETACL" SP mailbox

   identifier      = astring

   listrights      = "LISTRIGHTS" SP mailbox SP identifier

   listrights-data = "LISTRIGHTS" SP mailbox SP identifier
                           SP rights *(SP rights)




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


   mailbox-data    =/ acl-data / listrights-data / myrights-data
                       ;;mailbox-data is defined in [IMAP4]

   mod-rights      = astring
                       ;; +rights to add, -rights to remove
                       ;; rights to replace

   myrights        = "MYRIGHTS" SP mailbox

   myrights-data   = "MYRIGHTS" SP mailbox SP rights

   new-rights      = 1*LOWER-ALPHA
                       ;; MUST include "t", "e", "x", and "k".
                       ;; MUST NOT include standard rights listed
                       ;; in section 2.2

   rights          = astring
                       ;; only lowercase ASCII letters and digits
                       ;; are allowed.

   rights-capa     = "RIGHTS=" new-rights
                       ;; RIGHTS=... capability

   setacl          = "SETACL" SP mailbox SP identifier
                       SP mod-rights

8.  IANA Considerations

   IMAP4 capabilities are registered by publishing a standards-track or
   IESG-approved experimental RFC.  The registry is currently located
   at:

      http://www.iana.org/assignments/imap4-capabilities

   This document defines the RIGHTS= IMAP capability.  IANA has added
   this capability to the registry.

9.  Internationalization Considerations

   Section 3 states requirements on servers regarding
   internationalization of identifiers.










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


Appendix A.  Changes since RFC 2086

   1.   Changed the charset of "identifier" from US-ASCII to UTF-8.
   2.   Specified that mailbox deletion is controlled by the "x" right
        and EXPUNGE is controlled by the "e" right.
   3.   Added the "t" right that controls STORE \Deleted.  Redefined the
        "d" right to be a macro for "e", "t", and possibly "x".
   4.   Added the "k" right that controls CREATE.  Redefined the "c"
        right to be a macro for "k" and possibly "x".
   5.   Specified that the "a" right also controls DELETEACL.
   6.   Specified that the "r" right also controls STATUS.
   7.   Removed the requirement to check the "r" right for CHECK, SEARCH
        and FETCH, as this is required for SELECT/EXAMINE to be
        successful.
   8.   LISTRIGHTS requires the "a" right on the mailbox (same as
        SETACL).
   9.   Deleted "PARTIAL", this is a deprecated feature of RFC 1730.
   10.  Specified that the "w" right controls setting flags other than
        \Seen and \Deleted on APPEND.  Also specified that the "s" right
        controls the \Seen flag and that the "t" right controls the
        \Deleted flag.
   11.  Specified that SUBSCRIBE is NOT allowed with the "r" right.
   12.  Specified that the "l" right controls SUBSCRIBE.
   13.  GETACL is NOT allowed with the "r" right, even though there are
        several implementations that allows that.  If a user only has
        "r" right, GETACL can disclose information about identifiers
        existing on the mail system.
   14.  Clarified that RENAME requires the "k" right for the new parent
        and the "x" right for the old name.
   15.  Added new section that describes which rights are required
        and/or checked when performing various IMAP commands.
   16.  Added mail client security considerations when dealing with
        special identifier "anyone".
   17.  Clarified that negative rights are not the same as DELETEACL.
   18.  Added "Compatibility with RFC 2086" section.
   19.  Added section about mapping of ACL rights to READ-WRITE and
        READ-ONLY response codes.
   20.  Changed BNF to ABNF.
   21.  Added "Implementation Notes" section.
   22.  Updated "References" section.
   23.  Added more examples.
   24.  Clarified when the virtual "c" and "d" rights are returned in
        ACL, MYRIGHTS, and LISTRIGHTS responses.








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


Appendix B.  Compatibility with RFC 2086

   This non-normative section gives guidelines as to how an existing RFC
   2086 server implementation may be updated to comply with this
   document.

   This document splits the "d" right into several new different rights:
   "t", "e", and possibly "x" (see Section 2.1.1 for more details).  The
   "d" right remains for backward-compatibility, but it is a virtual
   right.  There are two approaches for RFC 2086 server implementors to
   handle the "d" right and the new rights that have replaced it:

   a.  Tie "t", "e" (and possibly "x) together - almost no changes.
   b.  Implement separate "x", "t" and "e".  Return the "d" right in a
       MYRIGHTS response or an ACL response containing ACL information
       when any of the "t", "e" (and "x") is granted.

   In a similar manner this document splits the "c" right into several
   new different rights: "k" and possibly "x" (see Section 2.1.1 for
   more details).  The "c" right remains for backwards-compatibility but
   it is a virtual right.  Again, RFC 2086 server implementors can
   choose to tie rights or to implement separate rights, as described
   above.

   Also check Sections 5.1.1 and 5.1.2, as well as Appendix A, to see
   other changes required.  Server implementors should check which
   rights are required to invoke different IMAP4 commands as described
   in Section 4.

Appendix C.  Known Deficiencies

   This specification has some known deficiencies including:

   1.  This is inadequate to provide complete read-write access to
       mailboxes protected by Unix-style rights bits because there is no
       equivalent to "chown" and "chgrp" commands nor is there a good
       way to discover such limitations are present.
   2.  Because this extension leaves the specific semantics of how
       rights are combined by the server as implementation defined, the
       ability to build a user-friendly interface is limited.
   3.  Users, groups, and special identifiers (e.g., anyone) exist in
       the same namespace.

   The work-in-progress "ACL2" extension is intended to redesign this
   extension to address these deficiencies without the constraint of
   backward-compatibility and may eventually supercede this facility.





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


   However, RFC 2086 is deployed in multiple implementations so this
   intermediate step, which fixes the straightforward deficiencies in a
   backward-compatible fashion, is considered worthwhile.

Appendix D.  Acknowledgements

   This document is a revision of RFC 2086 written by John G. Myers.

   Editor appreciates comments received from Mark Crispin, Chris Newman,
   Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole,
   Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie
   Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon
   Nerenberg, Lisa Dusseault, Arnt Gulbrandsen, and other participants
   of the IMAPEXT working group.

Normative References

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 4234, October 2005.

   [IMAP4]      Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
                4rev1", RFC 3501, March 2003.

   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, November 2003.

   [Stringprep] Hoffman, P. and M. Blanchet, "Preparation of
                Internationalized Strings ("stringprep")", RFC 3454,
                December 2002.

   [SASLprep]   Zeilenga, K., "SASLprep: Stringprep Profile for User
                Names and Passwords", RFC 4013, February 2005.

Informative References

   [RFC2086]    Myers, J., "IMAP4 ACL extension", RFC 2086,
                January 1997.

   [PR29]       "Public Review Issue #29: Normalization Issue",
                February 2004,
                <http://www.unicode.org/review/pr-29.html>.







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


Author's Address

   Alexey Melnikov
   Isode Ltd.
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   GB

   EMail: [e-mail]









































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


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Melnikov                    Standards Track                    [Page 27]