As per Relevance of the word implementation, we have this rfc below:
Network Working Group J.
Request for Comments: 2086 Carnegie
Category: Standards Track January 1997
IMAP4 ACL
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
1.
The ACL extension of the Internet Message Access Protocol [IMAP4]
permits access control lists to be manipulated through the
protocol
Table of
1. Abstract............................................... 1
2. Conventions Used in this Document...................... 1
3. Introduction and Overview.............................. 2
4. Commands............................................... 3
4.1. SETACL................................................. 3
4.2. DELETEACL.............................................. 4
4.3. GETACL................................................. 4
4.4. LISTRIGHTS............................................. 4
4.5. MYRIGHTS............................................... 5
5. Responses.............................................. 5
5.1. ACL.................................................... 5
5.2. LISTRIGHTS............................................. 6
5.3. MYRIGHTS............................................... 6
6. Formal Syntax.......................................... 6
7. References............................................. 7
8. Security Considerations................................ 7
9. Author's Address....................................... 8
2. Conventions Used in this
In examples, "C:" and "S:" indicate lines sent by the client
server respectively
Myers Standards Track [Page 1]
RFC 2086 ACL extension January 1997
3. Introduction and
The ACL extension is present in any IMAP4 implementation
returns "ACL" as one of the supported capabilities to the
command
An access control list is a set of <identifier,rights> pairs
Identifier is a US-ASCII string. The identifier anyone is
to refer to the universal identity (all authentications,
anonymous). All user name strings accepted by the LOGIN
AUTHENTICATE commands to authenticate to the IMAP server are
as identifiers for the corresponding user. Identifiers starting
a dash ("-") are reserved for "negative rights", described below
All other identifier strings are interpreted in an implementation
defined manner
Rights is a string listing a (possibly empty) set of
characters, each character listing a set of operations which is
controlled. Letters are reserved for ``standard'' rights,
below. The set of standard rights may only be extended by
standards-track document. Digits are reserved for implementation
site defined rights. The currently defined standard rights are
l - lookup (mailbox is visible to LIST/LSUB commands
r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL
SEARCH, COPY from mailbox
s - keep seen/unseen information across sessions (STORE SEEN flag
w - write (STORE flags other than SEEN and DELETED
i - insert (perform APPEND, COPY into mailbox
p - post (send mail to submission address for mailbox
not enforced by IMAP4 itself
c - create (CREATE new sub-mailboxes in any implementation-
hierarchy
d - delete (STORE DELETED flag, perform EXPUNGE
a - administer (perform SETACL
An implementation may tie rights together or may force rights
always or never be granted to particular identifiers. For example
in an implementation that uses unix mode bits, the rights "wisd"
tied, the "a" right is always granted to the owner of a mailbox
is never granted to another user. If rights are tied in
implementation, the implementation must be conservative in
rights in response to SETACL commands--unless all rights in a
set are specified, none of that set should be included in the
entry for that identifier. A client may discover the set of
which may be granted to a given identifier in the ACL for a
mailbox by using the LISTRIGHTS command
Myers Standards Track [Page 2]
RFC 2086 ACL extension January 1997
It is possible for multiple identifiers in an access control list
apply to a given user (or other authentication identity).
example, an ACL may include rights to be granted to the
matching the user, one or more implementation-defined
matching groups which include the user, and/or the
"anyone". How these rights are combined to determine the user'
access is implementation-defined. An implementation may choose,
example, to use the union of the rights granted to the
identifiers. An implementation may instead choose, for example,
only use those rights granted to the most specific identifier
in the ACL. A client may determine the set of rights granted to
logged-in user for a given mailbox by using the MYRIGHTS command
When an identifier in an ACL starts with a dash ("-"), that
that associated rights are to be removed from the identifier that
prefixed by the dash. For example, if the identifier "-fred"
granted the "w" right, that indicates that the "w" right is to
removed from users matching the identifier "fred".
need not support having identifiers which start with a dash in ACLs
4.
4.1.
Arguments: mailbox
authentication
access right
Data: no specific data for this
Result: OK - setacl
NO - setacl failure: can't set
BAD - command unknown or arguments
The SETACL command changes the access control list on
specified mailbox so that the specified identifier is
permissions as specified in the third argument
The third argument is a string containing an optional plus ("+")
or minus ("-") prefix, followed by zero or more rights characters
If the string starts with a plus, the following rights are
to any existing rights for the identifier. If the string
with a minus, the following rights are removed from any
rights for the identifier. If the string does not start with
plus or minus, the rights replace any existing rights for
identifier
Myers Standards Track [Page 3]
RFC 2086 ACL extension January 1997
4.2.
Arguments: mailbox
authentication
Data: no specific data for this
Result: OK - deleteacl
NO - deleteacl failure: can't delete
BAD - command unknown or arguments
The DELETEACL command removes any <identifier,rights> pair for
specified identifier from the access control list for the
mailbox
4.3.
Arguments: mailbox
Data: untagged responses:
Result: OK - getacl
NO - getacl failure: can't get
BAD - command unknown or arguments
The GETACL command returns the access control list for mailbox
an untagged ACL reply
Example: C: A002 GETACL
S: * ACL INBOX Fred
S: A002 OK Getacl
4.4.
Arguments: mailbox
authentication
Data: untagged responses:
Result: OK - listrights
NO - listrights failure: can't get rights
BAD - command unknown or arguments
The LISTRIGHTS command takes a mailbox name and an identifier
returns information about what rights may be granted to the
in the ACL for the mailbox
Myers Standards Track [Page 4]
RFC 2086 ACL extension January 1997
Example: C: a001 LISTRIGHTS ~/Mail/saved
S: * LISTRIGHTS ~/Mail/saved smith la r
S: a001 OK Listrights
C: a005 LISTRIGHTS archive.imap
S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d
0 1 2 3 4 5 6 7 8 9
4.5.
Arguments: mailbox
Data: untagged responses:
Result: OK - myrights
NO - myrights failure: can't get
BAD - command unknown or arguments
The MYRIGHTS command returns the set of rights that the user
to mailbox in an untagged MYRIGHTS reply
Example: C: A003 MYRIGHTS
S: * MYRIGHTS INBOX
S: A003 OK Myrights
5.
5.1.
Data: mailbox
zero or more identifier rights
The ACL response occurs as a result of a GETACL command. The
string is the mailbox name for which this ACL applies. This
followed by zero or more pairs of strings, each pair contains
identifier for which the entry applies followed by the set
rights that the identifier has
Myers Standards Track [Page 5]
RFC 2086 ACL extension January 1997
5.2.
Data: mailbox
required
list of optional
The LISTRIGHTS response occurs as a result of a
command. The first two strings are the mailbox name and
for which this rights list applies. Following the identifier is
string containing the (possibly empty) set of rights
identifier will always be granted in the mailbox
Following this are zero or more strings each containing a set
rights the identifier may be granted in the mailbox.
mentioned in the same string are tied together--either all must
granted to the identifier in the mailbox or none may be granted
The same right may not be listed more than once in the
command
5.3.
Data: mailbox
The MYRIGHTS response occurs as a result of a MYRIGHTS command
The first string is the mailbox name for which these rights apply
The second string is the set of rights that the client has
6. Formal
The following syntax specification uses the augmented Backus-
Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
Non-terminals referenced but not defined below are as defined
[IMAP4].
Except as noted otherwise, all alphabetic characters are case
insensitive. The use of upper or lower case characters to
token strings is for editorial clarity only. Implementations
accept these strings in a case-insensitive fashion
Myers Standards Track [Page 6]
RFC 2086 ACL extension January 1997
acl_data ::= "ACL" SPACE mailbox *(SPACE identifier
rights
deleteacl ::= "DELETEACL" SPACE mailbox SPACE
getacl ::= "GETACL" SPACE
identifier ::=
listrights ::= "LISTRIGHTS" SPACE mailbox SPACE
listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE
SPACE rights *(SPACE rights
mod_rights ::=
;; +rights to add, -rights to
;; rights to
myrights ::= "MYRIGHTS" SPACE
myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE
rights ::=
setacl ::= "SETACL" SPACE mailbox SPACE
SPACE mod_
7.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
RFC 1730, University of Washington, December 1994.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
Messages", STD 11, RFC 822.
8. Security
An implementation must make sure the ACL commands themselves do
give information about mailboxes with appropriately restricted ACL's
For example, a GETACL command on a mailbox for which the user
insufficient rights should not admit the mailbox exists, much
return the mailbox's ACL
Myers Standards Track [Page 7]
RFC 2086 ACL extension January 1997
9. Author's
John G.
Carnegie-Mellon
5000 Forbes Ave
Pittsburgh PA, 15213-3890
Email: jgm+@cmu.
Myers Standards Track [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
