;; 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.
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.
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.
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>.
Author’s Address
Alexey Melnikov
Isode Ltd.
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
GB
EMail: alexey.melnikov@isode.com
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-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.