You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by ba...@apache.org on 2006/07/29 15:16:01 UTC
svn commit: r426798 [12/30] - in
/james/server/trunk/src/site/resources/rfclist: ./ basic/ imap4/ ldap/
nntp/ pop3/ smtp/
Added: james/server/trunk/src/site/resources/rfclist/imap4/rfc2192.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/imap4/rfc2192.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/imap4/rfc2192.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/imap4/rfc2192.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,900 @@
+
+
+
+
+
+Network Working Group C. Newman
+Request for Comments: 2192 Innosoft
+Category: Standards Track September 1997
+
+
+ IMAP URL Scheme
+
+
+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.
+
+
+Abstract
+
+ IMAP [IMAP4] is a rich protocol for accessing remote message
+ stores. It provides an ideal mechanism for accessing public
+ mailing list archives as well as private and shared message stores.
+ This document defines a URL scheme for referencing objects on an
+ IMAP server.
+
+
+1. Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ in this document are to be interpreted as defined in "Key words for
+ use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+
+2. IMAP scheme
+
+ The IMAP URL scheme is used to designate IMAP servers, mailboxes,
+ messages, MIME bodies [MIME], and search programs on Internet hosts
+ accessible using the IMAP protocol.
+
+ The IMAP URL follows the common Internet scheme syntax as defined
+ in RFC 1738 [BASIC-URL] except that clear text passwords are not
+ permitted. If :<port> is omitted, the port defaults to 143.
+
+
+
+
+
+
+
+
+Newman Standards Track [Page 1]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ An IMAP URL takes one of the following forms:
+
+ imap://<iserver>/
+ imap://<iserver>/<enc_list_mailbox>;TYPE=<list_type>
+ imap://<iserver>/<enc_mailbox>[uidvalidity][?<enc_search>]
+ imap://<iserver>/<enc_mailbox>[uidvalidity]<iuid>[isection]
+
+ The first form is used to refer to an IMAP server, the second form
+ refers to a list of mailboxes, the third form refers to the
+ contents of a mailbox or a set of messages resulting from a search,
+ and the final form refers to a specific message or message part.
+ Note that the syntax here is informal. The authoritative formal
+ syntax for IMAP URLs is defined in section 11.
+
+
+3. IMAP User Name and Authentication Mechanism
+
+ A user name and/or authentication mechanism may be supplied. They
+ are used in the "LOGIN" or "AUTHENTICATE" commands after making the
+ connection to the IMAP server. If no user name or authentication
+ mechanism is supplied, the user name "anonymous" is used with the
+ "LOGIN" command and the password is supplied as the Internet e-mail
+ address of the end user accessing the resource. If the URL doesn't
+ supply a user name, the program interpreting the IMAP URL SHOULD
+ request one from the user if necessary.
+
+ An authentication mechanism can be expressed by adding
+ ";AUTH=<enc_auth_type>" to the end of the user name. When such an
+ <enc_auth_type> is indicated, the client SHOULD request appropriate
+ credentials from that mechanism and use the "AUTHENTICATE" command
+ instead of the "LOGIN" command. If no user name is specified, one
+ SHOULD be obtained from the mechanism or requested from the user as
+ appropriate.
+
+ The string ";AUTH=*" indicates that the client SHOULD select an
+ appropriate authentication mechanism. It MAY use any mechanism
+ listed in the CAPABILITY command or use an out of band security
+ service resulting in a PREAUTH connection. If no user name is
+ specified and no appropriate authentication mechanisms are
+ available, the client SHOULD fall back to anonymous login as
+ described above. This allows a URL which grants read-write access
+ to authorized users, and read-only anonymous access to other users.
+
+ If a user name is included with no authentication mechanism, then
+ ";AUTH=*" is assumed.
+
+
+
+
+
+
+Newman Standards Track [Page 2]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ Since URLs can easily come from untrusted sources, care must be
+ taken when resolving a URL which requires or requests any sort of
+ authentication. If authentication credentials are supplied to the
+ wrong server, it may compromise the security of the user's account.
+ The program resolving the URL should make sure it meets at least
+ one of the following criteria in this case:
+
+ (1) The URL comes from a trusted source, such as a referral server
+ which the client has validated and trusts according to site policy.
+ Note that user entry of the URL may or may not count as a trusted
+ source, depending on the experience level of the user and site
+ policy.
+ (2) Explicit local site policy permits the client to connect to the
+ server in the URL. For example, if the client knows the site
+ domain name, site policy may dictate that any hostname ending in
+ that domain is trusted.
+ (3) The user confirms that connecting to that domain name with the
+ specified credentials and/or mechanism is permitted.
+ (4) A mechanism is used which validates the server before passing
+ potentially compromising client credentials.
+ (5) An authentication mechanism is used which will not reveal
+ information to the server which could be used to compromise future
+ connections.
+
+ URLs which do not include a user name must be treated with extra
+ care, since they are more likely to compromise the user's primary
+ account. A URL containing ";AUTH=*" must also be treated with
+ extra care since it might fall back on a weaker security mechanism.
+ Finally, clients are discouraged from using a plain text password
+ as a fallback with ";AUTH=*" unless the connection has strong
+ encryption (e.g. a key length of greater than 56 bits).
+
+ A program interpreting IMAP URLs MAY cache open connections to an
+ IMAP server for later re-use. If a URL contains a user name, only
+ connections authenticated as that user may be re-used. If a URL
+ does not contain a user name or authentication mechanism, then only
+ an anonymous connection may be re-used. If a URL contains an
+ authentication mechanism without a user name, then any non-
+ anonymous connection may be re-used.
+
+ Note that if unsafe or reserved characters such as " " or ";" are
+ present in the user name or authentication mechanism, they MUST be
+ encoded as described in RFC 1738 [BASIC-URL].
+
+
+
+
+
+
+
+
+Newman Standards Track [Page 3]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+4. IMAP server
+
+ An IMAP URL referring to an IMAP server has the following form:
+
+ imap://<iserver>/
+
+ A program interpreting this URL would issue the standard set of
+ commands it uses to present a view of the contents of an IMAP
+ server. This is likely to be semanticly equivalent to one of the
+ following URLs:
+
+ imap://<iserver>/;TYPE=LIST
+ imap://<iserver>/;TYPE=LSUB
+
+ The program interpreting this URL SHOULD use the LSUB form if it
+ supports mailbox subscriptions.
+
+
+5. Lists of mailboxes
+
+ An IMAP URL referring to a list of mailboxes has the following
+ form:
+
+ imap://<iserver>/<enc_list_mailbox>;TYPE=<list_type>
+
+ The <list_type> may be either "LIST" or "LSUB", and is case
+ insensitive. The field ";TYPE=<list_type>" MUST be included.
+
+ The <enc_list_mailbox> is any argument suitable for the
+ list_mailbox field of the IMAP [IMAP4] LIST or LSUB commands. The
+ field <enc_list_mailbox> may be omitted, in which case the program
+ interpreting the IMAP URL may use "*" or "%" as the
+ <enc_list_mailbox>. The program SHOULD use "%" if it supports a
+ hierarchical view, otherwise it SHOULD use "*".
+
+ Note that if unsafe or reserved characters such as " " or "%" are
+ present in <enc_list_mailbox> they MUST be encoded as described in
+ RFC 1738 [BASIC-URL]. If the character "/" is present in
+ enc_list_mailbox, it SHOULD NOT be encoded.
+
+
+6. Lists of messages
+
+ An IMAP URL referring to a list of messages has the following form:
+
+ imap://<iserver>/<enc_mailbox>[uidvalidity][?<enc_search>]
+
+
+
+
+
+Newman Standards Track [Page 4]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ The <enc_mailbox> field is used as the argument to the IMAP4
+ "SELECT" command. Note that if unsafe or reserved characters such
+ as " ", ";", or "?" are present in <enc_mailbox> they MUST be
+ encoded as described in RFC 1738 [BASIC-URL]. If the character "/"
+ is present in enc_mailbox, it SHOULD NOT be encoded.
+
+ The [uidvalidity] field is optional. If it is present, it MUST be
+ the argument to the IMAP4 UIDVALIDITY status response at the time
+ the URL was created. This SHOULD be used by the program
+ interpreting the IMAP URL to determine if the URL is stale.
+
+ The [?<enc_search>] field is optional. If it is not present, the
+ contents of the mailbox SHOULD be presented by the program
+ interpreting the URL. If it is present, it SHOULD be used as the
+ arguments following an IMAP4 SEARCH command with unsafe characters
+ such as " " (which are likely to be present in the <enc_search>)
+ encoded as described in RFC 1738 [BASIC-URL].
+
+
+7. A specific message or message part
+
+ An IMAP URL referring to a specific message or message part has the
+ following form:
+
+ imap://<iserver>/<enc_mailbox>[uidvalidity]<iuid>[isection]
+
+ The <enc_mailbox> and [uidvalidity] are as defined above.
+
+ If [uidvalidity] is present in this form, it SHOULD be used by the
+ program interpreting the URL to determine if the URL is stale.
+
+ The <iuid> refers to an IMAP4 message UID, and SHOULD be used as
+ the <set> argument to the IMAP4 "UID FETCH" command.
+
+ The [isection] field is optional. If not present, the URL refers
+ to the entire Internet message as returned by the IMAP command "UID
+ FETCH <uid> BODY.PEEK[]". If present, the URL refers to the object
+ returned by a "UID FETCH <uid> BODY.PEEK[<section>]" command. The
+ type of the object may be determined with a "UID FETCH <uid>
+ BODYSTRUCTURE" command and locating the appropriate part in the
+ resulting BODYSTRUCTURE. Note that unsafe characters in [isection]
+ MUST be encoded as described in [BASIC-URL].
+
+
+
+
+
+
+
+
+
+Newman Standards Track [Page 5]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+8. Relative IMAP URLs
+
+ Relative IMAP URLs are permitted and are resolved according to the
+ rules defined in RFC 1808 [REL-URL] with one exception. In IMAP
+ URLs, parameters are treated as part of the normal path with
+ respect to relative URL resolution. This is believed to be the
+ behavior of the installed base and is likely to be documented in a
+ future revision of the relative URL specification.
+
+ The following observations are also important:
+
+ The <iauth> grammar element is considered part of the user name for
+ purposes of resolving relative IMAP URLs. This means that unless a
+ new login/server specification is included in the relative URL, the
+ authentication mechanism is inherited from a base IMAP URL.
+
+ URLs always use "/" as the hierarchy delimiter for the purpose of
+ resolving paths in relative URLs. IMAP4 permits the use of any
+ hierarchy delimiter in mailbox names. For this reason, relative
+ mailbox paths will only work if the mailbox uses "/" as the
+ hierarchy delimiter. Relative URLs may be used on mailboxes which
+ use other delimiters, but in that case, the entire mailbox name
+ MUST be specified in the relative URL or inherited as a whole from
+ the base URL.
+
+ The base URL for a list of mailboxes or messages which was referred
+ to by an IMAP URL is always the referring IMAP URL itself. The
+ base URL for a message or message part which was referred to by an
+ IMAP URL may be more complicated to determine. The program
+ interpreting the relative URL will have to check the headers of the
+ MIME entity and any enclosing MIME entities in order to locate the
+ "Content-Base" and "Content-Location" headers. These headers are
+ used to determine the base URL as defined in [HTTP]. For example,
+ if the referring IMAP URL contains a "/;SECTION=1.2" parameter,
+ then the MIME headers for section 1.2, for section 1, and for the
+ enclosing message itself SHOULD be checked in that order for
+ "Content-Base" or "Content-Location" headers.
+
+
+9. Multinational Considerations
+
+ IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding
+ non-US-ASCII characters in IMAP mailbox names. Because this
+ convention is private to IMAP, it is necessary to convert IMAP's
+ encoding to one that can be more easily interpreted by a URL
+ display program. For this reason, IMAP's modified UTF-7 encoding
+ for mailboxes MUST be converted to UTF-8 [UTF8]. Since 8-bit
+ characters are not permitted in URLs, the UTF-8 characters are
+
+
+
+Newman Standards Track [Page 6]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ encoded as required by the URL specification [BASIC-URL]. Sample
+ code is included in Appendix A to demonstrate this conversion.
+
+
+10. Examples
+
+ The following examples demonstrate how an IMAP4 client program
+ might translate various IMAP4 URLs into a series of IMAP4 commands.
+ Commands sent from the client to the server are prefixed with "C:",
+ and responses sent from the server to the client are prefixed with
+ "S:".
+
+ The URL:
+
+ <imap://minbari.org/gray-council;UIDVALIDITY=385759045/;UID=20>
+
+ Results in the following client commands:
+
+ <connect to minbari.org, port 143>
+ C: A001 LOGIN ANONYMOUS sheridan@babylon5.org
+ C: A002 SELECT gray-council
+ <client verifies the UIDVALIDITY matches>
+ C: A003 UID FETCH 20 BODY.PEEK[]
+
+ The URL:
+
+ <imap://michael@minbari.org/users.*;type=list>
+
+ Results in the following client commands:
+
+ <client requests password from user>
+ <connect to minbari.org imap server, activate strong encryption>
+ C: A001 LOGIN MICHAEL zipper
+ C: A002 LIST "" users.*
+
+ The URL:
+
+ <imap://psicorp.org/~peter/%E6%97%A5%E6%9C%AC%E8%AA%9E/
+ %E5%8F%B0%E5%8C%97>
+
+ Results in the following client commands:
+
+ <connect to psicorp.org, port 143>
+ C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.org
+ C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw-
+ <commands the client uses for viewing the contents of a mailbox>
+
+
+
+
+
+Newman Standards Track [Page 7]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ The URL:
+
+ <imap://;AUTH=KERBEROS_V4@minbari.org/gray-council/;uid=20/
+ ;section=1.2>
+
+ Results in the following client commands:
+
+ <connect to minbari.org, port 143>
+ C: A001 AUTHENTICATE KERBEROS_V4
+ <authentication exchange>
+ C: A002 SELECT gray-council
+ C: A003 UID FETCH 20 BODY.PEEK[1.2]
+
+ If the following relative URL is located in that body part:
+
+ <;section=1.4>
+
+ This could result in the following client commands:
+
+ C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME]
+ BODY.PEEK[1.MIME]
+ BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)])
+ <Client looks for Content-Base or Content-Location headers in
+ result. If no such headers, then it does the following>
+ C: A005 UID FETCH 20 BODY.PEEK[1.4]
+
+ The URL:
+
+ <imap://;AUTH=*@minbari.org/gray%20council?SUBJECT%20shadows>
+
+ Could result in the following:
+
+ <connect to minbari.org, port 143>
+ C: A001 CAPABILITY
+ S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI
+ S: A001 OK
+ C: A002 AUTHENTICATE GSSAPI
+ <authentication exchange>
+ S: A002 OK user lennier authenticated
+ C: A003 SELECT "gray council"
+ ...
+ C: A004 SEARCH SUBJECT shadows
+ S: * SEARCH 8 10 13 14 15 16
+ S: A004 OK SEARCH completed
+ C: A005 FETCH 8,10,13:16 ALL
+ ...
+
+
+
+
+
+Newman Standards Track [Page 8]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ NOTE: In this final example, the client has implementation
+ dependent choices. The authentication mechanism could be anything,
+ including PREAUTH. And the final FETCH command could fetch more or
+ less information about the messages, depending on what it wishes to
+ display to the user.
+
+
+11. Security Considerations
+
+ Security considerations discussed in the IMAP specification [IMAP4]
+ and the URL specification [BASIC-URL] are relevant. Security
+ considerations related to authenticated URLs are discussed in
+ section 3 of this document.
+
+ Many email clients store the plain text password for later use
+ after logging into an IMAP server. Such clients MUST NOT use a
+ stored password in response to an IMAP URL without explicit
+ permission from the user to supply that password to the specified
+ host name.
+
+
+12. ABNF for IMAP URL scheme
+
+ This uses ABNF as defined in RFC 822 [IMAIL]. Terminals from the
+ BNF for IMAP [IMAP4] and URLs [BASIC-URL] are also used. Strings
+ are not case sensitive and free insertion of linear-white-space is
+ not permitted.
+
+ achar = uchar / "&" / "=" / "~"
+ ; see [BASIC-URL] for "uchar" definition
+
+ bchar = achar / ":" / "@" / "/"
+
+ enc_auth_type = 1*achar
+ ; encoded version of [IMAP-AUTH] "auth_type"
+
+ enc_list_mailbox = 1*bchar
+ ; encoded version of [IMAP4] "list_mailbox"
+
+ enc_mailbox = 1*bchar
+ ; encoded version of [IMAP4] "mailbox"
+
+ enc_search = 1*bchar
+ ; encoded version of search_program below
+
+ enc_section = 1*bchar
+ ; encoded version of section below
+
+
+
+
+Newman Standards Track [Page 9]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ enc_user = 1*achar
+ ; encoded version of [IMAP4] "userid"
+
+ imapurl = "imap://" iserver "/" [ icommand ]
+
+ iauth = ";AUTH=" ( "*" / enc_auth_type )
+
+ icommand = imailboxlist / imessagelist / imessagepart
+
+ imailboxlist = [enc_list_mailbox] ";TYPE=" list_type
+
+ imessagelist = enc_mailbox [ "?" enc_search ] [uidvalidity]
+
+ imessagepart = enc_mailbox [uidvalidity] iuid [isection]
+
+ isection = "/;SECTION=" enc_section
+
+ iserver = [iuserauth "@"] hostport
+ ; See [BASIC-URL] for "hostport" definition
+
+ iuid = "/;UID=" nz_number
+ ; See [IMAP4] for "nz_number" definition
+
+ iuserauth = enc_user [iauth] / [enc_user] iauth
+
+ list_type = "LIST" / "LSUB"
+
+ search_program = ["CHARSET" SPACE astring SPACE]
+ search_key *(SPACE search_key)
+ ; IMAP4 literals may not be used
+ ; See [IMAP4] for "astring" and "search_key"
+
+ section = section_text / (nz_number *["." nz_number]
+ ["." (section_text / "MIME")])
+ ; See [IMAP4] for "section_text" and "nz_number"
+
+ uidvalidity = ";UIDVALIDITY=" nz_number
+ ; See [IMAP4] for "nz_number" definition
+
+13. References
+
+ [BASIC-URL] Berners-Lee, Masinter, McCahill, "Uniform Resource
+ Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of
+ Minnesota, December 1994.
+
+ <ftp://ds.internic.net/rfc/rfc1738.txt>
+
+
+
+
+
+Newman Standards Track [Page 10]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
+ 4rev1", RFC 2060, University of Washington, December 1996.
+
+ <ftp://ds.internic.net/rfc/rfc2060.txt>
+
+ [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731,
+ Carnegie-Mellon University, December 1994.
+
+ <ftp://ds.internic.net/rfc/rfc1731.txt>
+
+ [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS,
+ January 1997.
+
+ <ftp://ds.internic.net/rfc/rfc2068.txt>
+
+ [IMAIL] Crocker, "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+ <ftp://ds.internic.net/rfc/rfc822.txt>
+
+ [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, Harvard University, March 1997.
+
+ <ftp://ds.internic.net/rfc/rfc2119.txt>
+
+ [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail
+ Extensions", RFC 2045, Innosoft, First Virtual, November 1996.
+
+ <ftp://ds.internic.net/rfc/rfc2045.txt>
+
+ [REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808,
+ UC Irvine, June 1995.
+
+ <ftp://ds.internic.net/rfc/rfc1808.txt>
+
+ [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and
+ ISO 10646", RFC 2044, Alis Technologies, October 1996.
+
+ <ftp://ds.internic.net/rfc/rfc2044.txt>
+
+14. Author's Address
+
+ Chris Newman
+ Innosoft International, Inc.
+ 1050 Lakes Drive
+ West Covina, CA 91790 USA
+ EMail: chris.newman@innosoft.com
+
+
+
+Newman Standards Track [Page 11]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+Appendix A. Sample code
+
+Here is sample C source code to convert between URL paths and IMAP
+mailbox names, taking into account mapping between IMAP's modified UTF-7
+[IMAP4] and hex-encoded UTF-8 which is more appropriate for URLs. This
+code has not been rigorously tested nor does it necessarily behave
+reasonably with invalid input, but it should serve as a useful example.
+This code just converts the mailbox portion of the URL and does not deal
+with parameters, query or server components of the URL.
+
+#include <stdio.h>
+#include <string.h>
+
+/* hexadecimal lookup table */
+static char hex[] = "0123456789ABCDEF";
+
+/* URL unsafe printable characters */
+static char urlunsafe[] = " \"#%&+:;<=>?@[\\]^`{|}";
+
+/* UTF7 modified base64 alphabet */
+static char base64chars[] =
+ "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,";
+#define UNDEFINED 64
+
+/* UTF16 definitions */
+#define UTF16MASK 0x03FFUL
+#define UTF16SHIFT 10
+#define UTF16BASE 0x10000UL
+#define UTF16HIGHSTART 0xD800UL
+#define UTF16HIGHEND 0xDBFFUL
+#define UTF16LOSTART 0xDC00UL
+#define UTF16LOEND 0xDFFFUL
+
+/* Convert an IMAP mailbox to a URL path
+ * dst needs to have roughly 4 times the storage space of src
+ * Hex encoding can triple the size of the input
+ * UTF-7 can be slightly denser than UTF-8
+ * (worst case: 8 octets UTF-7 becomes 9 octets UTF-8)
+ */
+void MailboxToURL(char *dst, char *src)
+{
+ unsigned char c, i, bitcount;
+ unsigned long ucs4, utf16, bitbuf;
+ unsigned char base64[256], utf8[6];
+
+
+
+
+
+
+
+Newman Standards Track [Page 12]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ /* initialize modified base64 decoding table */
+ memset(base64, UNDEFINED, sizeof (base64));
+ for (i = 0; i < sizeof (base64chars); ++i) {
+ base64[base64chars[i]] = i;
+ }
+
+ /* loop until end of string */
+ while (*src != '\0') {
+ c = *src++;
+ /* deal with literal characters and &- */
+ if (c != '&' || *src == '-') {
+ if (c < ' ' || c > '~' || strchr(urlunsafe, c) != NULL) {
+ /* hex encode if necessary */
+ dst[0] = '%';
+ dst[1] = hex[c >> 4];
+ dst[2] = hex[c & 0x0f];
+ dst += 3;
+ } else {
+ /* encode literally */
+ *dst++ = c;
+ }
+ /* skip over the '-' if this is an &- sequence */
+ if (c == '&') ++src;
+ } else {
+ /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */
+ bitbuf = 0;
+ bitcount = 0;
+ ucs4 = 0;
+ while ((c = base64[(unsigned char) *src]) != UNDEFINED) {
+ ++src;
+ bitbuf = (bitbuf << 6) | c;
+ bitcount += 6;
+ /* enough bits for a UTF-16 character? */
+ if (bitcount >= 16) {
+ bitcount -= 16;
+ utf16 = (bitcount ? bitbuf >> bitcount
+ : bitbuf) & 0xffff;
+ /* convert UTF16 to UCS4 */
+ if
+ (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) {
+ ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT;
+ continue;
+ } else if
+ (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) {
+ ucs4 += utf16 - UTF16LOSTART + UTF16BASE;
+ } else {
+ ucs4 = utf16;
+ }
+
+
+
+Newman Standards Track [Page 13]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ /* convert UTF-16 range of UCS4 to UTF-8 */
+ if (ucs4 <= 0x7fUL) {
+ utf8[0] = ucs4;
+ i = 1;
+ } else if (ucs4 <= 0x7ffUL) {
+ utf8[0] = 0xc0 | (ucs4 >> 6);
+ utf8[1] = 0x80 | (ucs4 & 0x3f);
+ i = 2;
+ } else if (ucs4 <= 0xffffUL) {
+ utf8[0] = 0xe0 | (ucs4 >> 12);
+ utf8[1] = 0x80 | ((ucs4 >> 6) & 0x3f);
+ utf8[2] = 0x80 | (ucs4 & 0x3f);
+ i = 3;
+ } else {
+ utf8[0] = 0xf0 | (ucs4 >> 18);
+ utf8[1] = 0x80 | ((ucs4 >> 12) & 0x3f);
+ utf8[2] = 0x80 | ((ucs4 >> 6) & 0x3f);
+ utf8[3] = 0x80 | (ucs4 & 0x3f);
+ i = 4;
+ }
+ /* convert utf8 to hex */
+ for (c = 0; c < i; ++c) {
+ dst[0] = '%';
+ dst[1] = hex[utf8[c] >> 4];
+ dst[2] = hex[utf8[c] & 0x0f];
+ dst += 3;
+ }
+ }
+ }
+ /* skip over trailing '-' in modified UTF-7 encoding */
+ if (*src == '-') ++src;
+ }
+ }
+ /* terminate destination string */
+ *dst = '\0';
+}
+
+/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox
+ * dst should be about twice the length of src to deal with non-hex
+ * coded URLs
+ */
+void URLtoMailbox(char *dst, char *src)
+{
+ unsigned int utf8pos, utf8total, i, c, utf7mode, bitstogo, utf16flag;
+ unsigned long ucs4, bitbuf;
+ unsigned char hextab[256];
+
+ /* initialize hex lookup table */
+
+
+
+Newman Standards Track [Page 14]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ memset(hextab, 0, sizeof (hextab));
+ for (i = 0; i < sizeof (hex); ++i) {
+ hextab[hex[i]] = i;
+ if (isupper(hex[i])) hextab[tolower(hex[i])] = i;
+ }
+
+ utf7mode = 0;
+ utf8total = 0;
+ bitstogo = 0;
+ while ((c = *src) != '\0') {
+ ++src;
+ /* undo hex-encoding */
+ if (c == '%' && src[0] != '\0' && src[1] != '\0') {
+ c = (hextab[src[0]] << 4) | hextab[src[1]];
+ src += 2;
+ }
+ /* normal character? */
+ if (c >= ' ' && c <= '~') {
+ /* switch out of UTF-7 mode */
+ if (utf7mode) {
+ if (bitstogo) {
+ *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
+ }
+ *dst++ = '-';
+ utf7mode = 0;
+ }
+ *dst++ = c;
+ /* encode '&' as '&-' */
+ if (c == '&') {
+ *dst++ = '-';
+ }
+ continue;
+ }
+ /* switch to UTF-7 mode */
+ if (!utf7mode) {
+ *dst++ = '&';
+ utf7mode = 1;
+ }
+ /* Encode US-ASCII characters as themselves */
+ if (c < 0x80) {
+ ucs4 = c;
+ utf8total = 1;
+ } else if (utf8total) {
+ /* save UTF8 bits into UCS4 */
+ ucs4 = (ucs4 << 6) | (c & 0x3FUL);
+ if (++utf8pos < utf8total) {
+ continue;
+ }
+
+
+
+Newman Standards Track [Page 15]
+
+RFC 2192 IMAP URL Scheme September 1997
+
+
+ } else {
+ utf8pos = 1;
+ if (c < 0xE0) {
+ utf8total = 2;
+ ucs4 = c & 0x1F;
+ } else if (c < 0xF0) {
+ utf8total = 3;
+ ucs4 = c & 0x0F;
+ } else {
+ /* NOTE: can't convert UTF8 sequences longer than 4 */
+ utf8total = 4;
+ ucs4 = c & 0x03;
+ }
+ continue;
+ }
+ /* loop to split ucs4 into two utf16 chars if necessary */
+ utf8total = 0;
+ do {
+ if (ucs4 >= UTF16BASE) {
+ ucs4 -= UTF16BASE;
+ bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT)
+ + UTF16HIGHSTART);
+ ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART;
+ utf16flag = 1;
+ } else {
+ bitbuf = (bitbuf << 16) | ucs4;
+ utf16flag = 0;
+ }
+ bitstogo += 16;
+ /* spew out base64 */
+ while (bitstogo >= 6) {
+ bitstogo -= 6;
+ *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo)
+ : bitbuf)
+ & 0x3F];
+ }
+ } while (utf16flag);
+ }
+ /* if in UTF-7 mode, finish in ASCII */
+ if (utf7mode) {
+ if (bitstogo) {
+ *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
+ }
+ *dst++ = '-';
+ }
+ /* tie off string */
+ *dst = '\0';
+}
+
+
+
+Newman Standards Track [Page 16]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/imap4/rfc2192.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/imap4/rfc2193.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/imap4/rfc2193.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/imap4/rfc2193.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/imap4/rfc2193.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,508 @@
+
+
+
+
+
+Network Working Group M. Gahrns
+Request for Comments: 2193 Microsoft
+Category: Standards Track September 1997
+
+
+ IMAP4 Mailbox Referrals
+
+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.
+
+1. Abstract
+
+ When dealing with large amounts of users, messages and geographically
+ dispersed IMAP4 [RFC-2060] servers, it is often desirable to
+ distribute messages amongst different servers within an organization.
+ For example an administrator may choose to store user's personal
+ mailboxes on a local IMAP4 server, while storing shared mailboxes
+ remotely on another server. This type of configuration is common
+ when it is uneconomical to store all data centrally due to limited
+ bandwidth or disk resources.
+
+ Mailbox referrals allow clients to seamlessly access mailboxes that
+ are distributed across several IMAP4 servers.
+
+ A referral mechanism can provide efficiencies over the alternative
+ "proxy method", in which the local IMAP4 server contacts the remote
+ server on behalf of the client, and then transfers the data from the
+ remote server to itself, and then on to the client. The referral
+ mechanism's direct client connection to the remote server is often a
+ more efficient use of bandwidth, and does not require the local
+ server to impersonate the client when authenticating to the remote
+ server.
+
+2. Conventions used in this document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+ A home server, is an IMAP4 server that contains the user's inbox.
+
+ A remote mailbox is a mailbox that is not hosted on the user's home
+ server.
+
+
+
+
+Gahrns Standards Track [Page 1]
+
+RFC 2193 IMAP4 Mailbox Referrals September 1997
+
+
+ A remote server is a server that contains remote mailboxes.
+
+ A shared mailbox, is a mailbox that multiple users have access to.
+
+ An IMAP mailbox referral is when the server directs the client to
+ another IMAP mailbox.
+
+ 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].
+
+3. Introduction and Overview
+
+ IMAP4 servers that support this extension MUST list the keyword
+ MAILBOX-REFERRALS in their CAPABILITY response. No client action is
+ needed to invoke the MAILBOX-REFERRALS capability in a server.
+
+ A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals
+ that result in a referrals loop.
+
+ A referral response consists of a tagged NO response and a REFERRAL
+ response code. The REFERRAL response code MUST contain as an
+ argument a one or more valid URLs separated by a space as defined in
+ [RFC-1738]. If a server replies with multiple URLs for a particular
+ object, they MUST all be of the same type. In this case, the URL MUST
+ be an IMAP URL as defined in [RFC-2192]. A client that supports the
+ REFERRALS extension MUST be prepared for a URL of any type, but it
+ need only be able to process IMAP URLs.
+
+ A server MAY respond with multiple IMAP mailbox referrals if there is
+ more than one replica of the mailbox. This allows the implementation
+ of a load balancing or failover scheme. How a server keeps multiple
+ replicas of a mailbox in sync is not addressed by this document.
+
+ If the server has a preferred order in which the client should
+ attempt to access the URLs, the preferred URL SHOULD be listed in the
+ first, with the remaining URLs presented in descending order of
+ preference. If multiple referrals are given for a mailbox, a server
+ should be aware that there are synchronization issues for a client if
+ the UIDVALIDITY of the referred mailboxes are different.
+
+ An IMAP mailbox referral may be given in response to an IMAP command
+ that specifies a mailbox as an argument.
+
+
+
+
+
+
+
+
+Gahrns Standards Track [Page 2]
+
+RFC 2193 IMAP4 Mailbox Referrals September 1997
+
+
+ Example:
+
+ A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox
+
+ NOTE: user;AUTH=* is specified as required by [RFC-2192] to avoid a
+ client falling back to anonymous login.
+
+ Remote mailboxes and their inferiors, that are accessible only via
+ referrals SHOULD NOT appear in LIST and LSUB responses issued against
+ the user's home server. They MUST appear in RLIST and RLSUB
+ responses issued against the user's home server. Hierarchy referrals,
+ in which a client would be required to connect to the remote server
+ to issue a LIST to discover the inferiors of a mailbox are not
+ addressed in this document.
+
+ For example, if shared mailboxes were only accessible via referrals
+ on a remote server, a RLIST "" "#SHARED/%" command would return the
+ same response if issued against the user's home server or the remote
+ server.
+
+ Note: Mailboxes that are available on the user's home server do not
+ need to be available on the remote server. In addition, there may be
+ additional mailboxes available on the remote server, but they will
+ not accessible to the client via referrals unless they appear in the
+ LIST response to the RLIST command against the user's home server.
+
+ A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB
+ commands in lieu of LIST and LSUB. The RLIST and RLSUB commands
+ behave identically to their LIST and LSUB counterparts, except remote
+ mailboxes are returned in addition to local mailboxes in the LIST and
+ LSUB responses. This avoids displaying to a non MAILBOX-REFERRALS
+ enabled client inaccessible remote mailboxes.
+
+4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND
+ Referrals
+
+ An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE,
+ SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more
+ IMAP mailbox referrals to indicate to the client that the mailbox is
+ hosted on a remote server.
+
+ When a client processes an IMAP mailbox referral, it will open a new
+ connection or use an existing connection to the remote server so that
+ it is able to issue the commands necessary to process the remote
+ mailbox.
+
+
+
+
+
+
+Gahrns Standards Track [Page 3]
+
+RFC 2193 IMAP4 Mailbox Referrals September 1997
+
+
+ Example: <IMAP4 connection to home server>
+
+ C: A001 DELETE "SHARED/FOO"
+ S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
+ Remote mailbox. Try SERVER2.
+
+ <Client established a second connection to SERVER2 and
+ issues the DELETE command on the referred mailbox>
+
+ S: * OK IMAP4rev1 server ready
+ C: B001 AUTHENTICATE KERBEROS_V4
+ <authentication exchange>
+ S: B001 OK user is authenticated
+
+ C: B002 DELETE "SHARED/FOO"
+ S: B002 OK DELETE completed
+
+ Example: <IMAP4 connection to home server>
+
+ C: A001 SELECT REMOTE
+ S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE
+ IMAP://user;AUTH=*@SERVER3/REMOTE] Remote mailbox.
+ Try SERVER2 or SERVER3.
+
+ <Client opens second connection to remote server, and
+ issues the commands needed to process the items in the
+ remote mailbox>
+
+ S: * OK IMAP4rev1 server ready
+ C: B001 AUTHENTICATE KERBEROS_V4
+ <authentication exchange>
+ S: B001 OK user is authenticated
+
+ C: B002 SELECT REMOTE
+ S: * 12 EXISTS
+ S: * 1 RECENT
+ S: * OK [UNSEEN 10] Message 10 is first unseen
+ S: * OK [UIDVALIDITY 123456789]
+ S: * FLAGS (Answered Flagged Deleted Seen Draft)
+ S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
+ S: B002 OK [READ-WRITE] Selected completed
+
+ C: B003 FETCH 10:12 RFC822
+ S: * 10 FETCH . . .
+ S: * 11 FETCH . . .
+ S: * 12 FETCH . . .
+ S: B003 OK FETCH Completed
+
+
+
+
+Gahrns Standards Track [Page 4]
+
+RFC 2193 IMAP4 Mailbox Referrals September 1997
+
+
+ <Client is finished processing the REMOTE mailbox and
+ wants to process a mailbox on its home server>
+
+ C: B004 LOGOUT
+ S: * BYE IMAP4rev1 server logging out
+ S: B004 OK LOGOUT Completed
+
+ <Client continues with first connection>
+
+ C: A002 SELECT INBOX
+ S: * 16 EXISTS
+ S: * 2 RECENT
+ S: * OK [UNSEEN 10] Message 10 is first unseen
+ S: * OK [UIDVALIDITY 123456789]
+ S: * FLAGS (Answered Flagged Deleted Seen Draft)
+ S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
+ S: A002 OK [READ-WRITE] Selected completed
+
+4.2. CREATE Referrals
+
+ An IMAP4 server MAY respond to the CREATE command with one or more
+ IMAP mailbox referrals, if it wishes to direct the client to issue
+ the CREATE against another server. The server can employ any means,
+ such as examining the hierarchy of the specified mailbox name, in
+ determining which server the mailbox should be created on.
+
+ Example:
+
+ C: A001 CREATE "SHARED/FOO"
+ S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
+ Mailbox should be created on remote server
+
+ Alternatively, because a home server is required to maintain a
+ listing of referred remote mailboxes, a server MAY allow the creation
+ of a mailbox that will ultimately reside on a remote server against
+ the home server, and provide referrals on subsequent commands that
+ manipulate the mailbox.
+
+ Example:
+
+ C: A001 CREATE "SHARED/FOO"
+ S: A001 OK CREATE succeeded
+
+ C: A002 SELECT "SHARED/FOO"
+ S: A002 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
+ Remote mailbox. Try SERVER2
+
+
+
+
+
+Gahrns Standards Track [Page 5]
+
+RFC 2193 IMAP4 Mailbox Referrals September 1997
+
+
+4.3. RENAME Referrals
+
+ An IMAP4 server MAY respond to the RENAME command with one or more
+ pairs of IMAP mailbox referrals. In each pair of IMAP mailbox
+ referrals, the first one is an URL to the existing mailbox name and
+ the second is an URL to the requested new mailbox name.
+
+ If within an IMAP mailbox referral pair, the existing and new mailbox
+ URLs are on different servers, the remote servers are unable to
+ perform the RENAME operation. To achieve the same behavior of
+ server RENAME, the client MAY issue the constituent CREATE, FETCH,
+ APPEND, and DELETE commands against both servers.
+
+ If within an IMAP mailbox referral pair, the existing and new mailbox
+ URLs are on the same server it is an indication that the currently
+ connected server is unable to perform the operation. The client can
+ simply re-issue the RENAME command on the remote server.
+
+ Example:
+
+ C: A001 RENAME FOO BAR
+ S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER1/FOO
+ IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
+ across servers
+
+ Since the existing and new mailbox names are on different servers,
+ the client would be required to make a connection to both servers and
+ issue the constituent commands require to achieve the RENAME.
+
+ Example:
+
+ C: A001 RENAME FOO BAR
+ S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/FOO
+ IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
+ located on SERVER2
+
+ Since both the existing and new mailbox are on the same remote
+ server, the client can simply make a connection to the remote server
+ and re-issue the RENAME command.
+
+4.4. COPY Referrals
+
+ An IMAP4 server MAY respond to the COPY command with one or more IMAP
+ mailbox referrals. This indicates that the destination mailbox is on
+ a remote server. To achieve the same behavior of a server COPY, the
+ client MAY issue the constituent FETCH and APPEND commands against
+ both servers.
+
+
+
+
+Gahrns Standards Track [Page 6]
+
+RFC 2193 IMAP4 Mailbox Referrals September 1997
+
+
+ Example:
+
+ C: A001 COPY 1 "SHARED/STUFF"
+ S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/STUFF]
+ Unable to copy message(s) to SERVER2.
+
+5.1 RLIST command
+
+ Arguments: reference name
+ mailbox name with possible wildcards
+
+ Responses: untagged responses: LIST
+
+ Result: OK - RLIST Completed
+ NO - RLIST Failure
+ BAD - command unknown or arguments invalid
+
+ The RLIST command behaves identically to its LIST counterpart, except
+ remote mailboxes are returned in addition to local mailboxes in the
+ LIST responses.
+
+5.2 RLSUB Command
+
+ Arguments: reference name
+ mailbox name with possible wildcards
+
+ Responses: untagged responses: LSUB
+
+ Result: OK - RLSUB Completed
+ NO - RLSUB Failure
+ BAD - command unknown or arguments invalid
+
+ The RLSUB command behaves identically to its LSUB counterpart, except
+ remote mailboxes are returned in addition to local mailboxes in the
+ LSUB responses.
+
+6. Formal Syntax
+
+ The following syntax specification uses the augmented Backus-Naur
+ Form (BNF) as described in [ABNF].
+
+ list_mailbox = <list_mailbox> as defined in [RFC-2060]
+
+ mailbox = <mailbox> as defined in [RFC-2060]
+
+ mailbox_referral = <tag> SPACE "NO" SPACE
+ <referral_response_code> (text / text_mime2)
+ ; See [RFC-2060] for <tag>, text and text_mime2 definition
+
+
+
+Gahrns Standards Track [Page 7]
+
+RFC 2193 IMAP4 Mailbox Referrals September 1997
+
+
+ referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"
+ ; See [RFC-1738] for <url> definition
+
+ rlist = "RLIST" SPACE mailbox SPACE list_mailbox
+
+ rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox
+
+6. Security Considerations
+
+ The IMAP4 referral mechanism makes use of IMAP URLs, and as such,
+ have the same security considerations as general internet URLs [RFC-
+ 1738], and in particular IMAP URLs [RFC-2192].
+
+ With the MAILBOX-REFERRALS capability, it is potentially easier to
+ write a rogue server that injects a bogus referral response that
+ directs a user to an incorrect mailbox. Although referrals reduce
+ the effort to write such a server, the referral response makes
+ detection of the intrusion easier.
+
+7. References
+
+ [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
+ 4rev1", RFC 2060, University of Washington, December 1996.
+
+ [RFC-2192], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
+ September 1997.
+
+ [RFC-1738], Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
+ University of Minnesota, December 1994.
+
+ [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, Harvard University, March 1997.
+
+ [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
+ Syntax Specifications: ABNF", Work in Progress, Internet Mail
+ Consortium, April 1997.
+
+8. Acknowledgments
+
+ Many valuable suggestions were received from private discussions and
+ the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin,
+ Mark Keasling, Chris Newman and Larry Osterman made significant
+ contributions to this document.
+
+
+
+
+
+
+
+Gahrns Standards Track [Page 8]
+
+RFC 2193 IMAP4 Mailbox Referrals September 1997
+
+
+9. Author's Address
+
+ Mike Gahrns
+ Microsoft
+ One Microsoft Way
+ Redmond, WA, 98072
+
+ Phone: (206) 936-9833
+ EMail: mikega@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns Standards Track [Page 9]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/imap4/rfc2193.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/imap4/rfc2195.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/imap4/rfc2195.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/imap4/rfc2195.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/imap4/rfc2195.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,284 @@
+
+
+
+
+
+Network Working Group J. Klensin
+Request for Comments: 2195 R. Catoe
+Category: Standards Track P. Krumviede
+Obsoletes: 2095 MCI
+ September 1997
+
+
+ IMAP/POP AUTHorize Extension for Simple Challenge/Response
+
+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.
+
+Abstract
+
+ While IMAP4 supports a number of strong authentication mechanisms as
+ described in RFC 1731, it lacks any mechanism that neither passes
+ cleartext, reusable passwords across the network nor requires either
+ a significant security infrastructure or that the mail server update
+ a mail-system-wide user authentication file on each mail access.
+ This specification provides a simple challenge-response
+ authentication protocol that is suitable for use with IMAP4. Since
+ it utilizes Keyed-MD5 digests and does not require that the secret be
+ stored in the clear on the server, it may also constitute an
+ improvement on APOP for POP3 use as specified in RFC 1734.
+
+1. Introduction
+
+ Existing Proposed Standards specify an AUTHENTICATE mechanism for the
+ IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
+ the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is
+ intended to be extensible; the four methods specified in [IMAP-AUTH]
+ are all fairly powerful and require some security infrastructure to
+ support. The base POP3 specification [POP3] also contains a
+ lightweight challenge-response mechanism called APOP. APOP is
+ associated with most of the risks associated with such protocols: in
+ particular, it requires that both the client and server machines have
+ access to the shared secret in cleartext form. CRAM offers a method
+ for avoiding such cleartext storage while retaining the algorithmic
+ simplicity of APOP in using only MD5, though in a "keyed" method.
+
+
+
+
+
+
+
+Klensin, Catoe & Krumviede Standards Track [Page 1]
+
+RFC 2195 IMAP/POP AUTHorize Extension September 1997
+
+
+ At present, IMAP [IMAP] lacks any facility corresponding to APOP.
+ The only alternative to the strong mechanisms identified in [IMAP-
+ AUTH] is a presumably cleartext username and password, supported
+ through the LOGIN command in [IMAP]. This document describes a
+ simple challenge-response mechanism, similar to APOP and PPP CHAP
+ [PPP], that can be used with IMAP (and, in principle, with POP3).
+
+ This mechanism also has the advantage over some possible alternatives
+ of not requiring that the server maintain information about email
+ "logins" on a per-login basis. While mechanisms that do require such
+ per-login history records may offer enhanced security, protocols such
+ as IMAP, which may have several connections between a given client
+ and server open more or less simultaneous, may make their
+ implementation particularly challenging.
+
+2. Challenge-Response Authentication Mechanism (CRAM)
+
+ The authentication type associated with CRAM is "CRAM-MD5".
+
+ The data encoded in the first ready response contains an
+ presumptively arbitrary string of random digits, a timestamp, and the
+ fully-qualified primary host name of the server. The syntax of the
+ unencoded form must correspond to that of an RFC 822 'msg-id'
+ [RFC822] as described in [POP3].
+
+ The client makes note of the data and then responds with a string
+ consisting of the user name, a space, and a 'digest'. The latter is
+ computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
+ the key is a shared secret and the digested text is the timestamp
+ (including angle-brackets).
+
+ This shared secret is a string known only to the client and server.
+ The `digest' parameter itself is a 16-octet value which is sent in
+ hexadecimal format, using lower-case ASCII characters.
+
+ When the server receives this client response, it verifies the digest
+ provided. If the digest is correct, the server should consider the
+ client authenticated and respond appropriately.
+
+ Keyed MD5 is chosen for this application because of the greater
+ security imparted to authentication of short messages. In addition,
+ the use of the techniques described in [KEYED-MD5] for precomputation
+ of intermediate results make it possible to avoid explicit cleartext
+ storage of the shared secret on the server system by instead storing
+ the intermediate results which are known as "contexts".
+
+
+
+
+
+
+Klensin, Catoe & Krumviede Standards Track [Page 2]
+
+RFC 2195 IMAP/POP AUTHorize Extension September 1997
+
+
+ CRAM does not support a protection mechanism.
+
+ Example:
+
+ The examples in this document show the use of the CRAM mechanism with
+ the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of
+ the challenges and responses is part of the IMAP4 AUTHENTICATE
+ command, not part of the CRAM specification itself.
+
+ S: * OK IMAP4 Server
+ C: A0001 AUTHENTICATE CRAM-MD5
+ S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
+ C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
+ S: A0001 OK CRAM authentication successful
+
+ In this example, the shared secret is the string
+ 'tanstaaftanstaaf'. Hence, the Keyed MD5 digest is produced by
+ calculating
+
+ MD5((tanstaaftanstaaf XOR opad),
+ MD5((tanstaaftanstaaf XOR ipad),
+ <18...@postoffice.reston.mci.net>))
+
+ where ipad and opad are as defined in the keyed-MD5 Work in
+ Progress [KEYED-MD5] and the string shown in the challenge is the
+ base64 encoding of <18...@postoffice.reston.mci.net>. The
+ shared secret is null-padded to a length of 64 bytes. If the
+ shared secret is longer than 64 bytes, the MD5 digest of the
+ shared secret is used as a 16 byte input to the keyed MD5
+ calculation.
+
+ This produces a digest value (in hexadecimal) of
+
+ b913a602c7eda7a495b4e6e7334d3890
+
+ The user name is then prepended to it, forming
+
+ tim b913a602c7eda7a495b4e6e7334d3890
+
+ Which is then base64 encoded to meet the requirements of the IMAP4
+ AUTHENTICATE command (or the similar POP3 AUTH command), yielding
+
+ dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
+
+
+
+
+
+
+
+
+Klensin, Catoe & Krumviede Standards Track [Page 3]
+
+RFC 2195 IMAP/POP AUTHorize Extension September 1997
+
+
+3. References
+
+ [CHAP] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
+ RFC 1334, October 1992.
+
+ [IMAP] Crispin, M., "Internet Message Access Protocol - Version
+ 4rev1", RFC 2060, University of Washington, December 1996.
+
+ [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
+ RFC 1731, Carnegie Mellon, December 1994.
+
+ [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
+ Message Authentication", RFC 2104, February 1997.
+
+ [MD5] Rivest, R., "The MD5 Message Digest Algorithm",
+ RFC 1321, MIT Laboratory for Computer Science, April 1992.
+
+ [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
+ STD 53, RFC 1939, Carnegie Mellon, May 1996.
+
+ [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
+ Carnegie Mellon, December, 1994.
+
+4. Security Considerations
+
+ It is conjectured that use of the CRAM authentication mechanism
+ provides origin identification and replay protection for a session.
+ Accordingly, a server that implements both a cleartext password
+ command and this authentication type should not allow both methods of
+ access for a given user.
+
+ While the saving, on the server, of "contexts" (see section 2) is
+ marginally better than saving the shared secrets in cleartext as is
+ required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
+ protect the secrets if the server itself is compromised.
+ Consequently, servers that store the secrets or contexts must both be
+ protected to a level appropriate to the potential information value
+ in user mailboxes and identities.
+
+ As the length of the shared secret increases, so does the difficulty
+ of deriving it.
+
+ While there are now suggestions in the literature that the use of MD5
+ and keyed MD5 in authentication procedures probably has a limited
+ effective lifetime, the technique is now widely deployed and widely
+ understood. It is believed that this general understanding may
+ assist with the rapid replacement, by CRAM-MD5, of the current uses
+ of permanent cleartext passwords in IMAP. This document has been
+
+
+
+Klensin, Catoe & Krumviede Standards Track [Page 4]
+
+RFC 2195 IMAP/POP AUTHorize Extension September 1997
+
+
+ deliberately written to permit easy upgrading to use SHA (or whatever
+ alternatives emerge) when they are considered to be widely available
+ and adequately safe.
+
+ Even with the use of CRAM, users are still vulnerable to active
+ attacks. An example of an increasingly common active attack is 'TCP
+ Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
+
+ See section 1 above for additional discussion.
+
+5. Acknowledgements
+
+ This memo borrows ideas and some text liberally from [POP3] and
+ [RFC-1731] and thanks are due the authors of those documents. Ran
+ Atkinson made a number of valuable technical and editorial
+ contributions to the document.
+
+6. Authors' Addresses
+
+ John C. Klensin
+ MCI Telecommunications
+ 800 Boylston St, 7th floor
+ Boston, MA 02199
+ USA
+
+ EMail: klensin@mci.net
+ Phone: +1 617 960 1011
+
+ Randy Catoe
+ MCI Telecommunications
+ 2100 Reston Parkway
+ Reston, VA 22091
+ USA
+
+ EMail: randy@mci.net
+ Phone: +1 703 715 7366
+
+ Paul Krumviede
+ MCI Telecommunications
+ 2100 Reston Parkway
+ Reston, VA 22091
+ USA
+
+ EMail: paul@mci.net
+ Phone: +1 703 715 7251
+
+
+
+
+
+
+Klensin, Catoe & Krumviede Standards Track [Page 5]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/imap4/rfc2195.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: james/server/trunk/src/site/resources/rfclist/imap4/rfc2221.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/imap4/rfc2221.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/imap4/rfc2221.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/imap4/rfc2221.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,284 @@
+
+
+
+
+
+Network Working Group M. Gahrns
+Request for Comments: 2221 Microsoft
+Category: Standards Track October 1997
+
+
+ IMAP4 Login Referrals
+
+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 (1997). All Rights Reserved.
+
+1. Abstract
+
+ When dealing with large amounts of users and many IMAP4 [RFC-2060]
+ servers, it is often necessary to move users from one IMAP4 server to
+ another. For example, hardware failures or organizational changes
+ may dictate such a move.
+
+ Login referrals allow clients to transparently connect to an
+ alternate IMAP4 server, if their home IMAP4 server has changed.
+
+ A referral mechanism can provide efficiencies over the alternative
+ 'proxy method', in which the local IMAP4 server contacts the remote
+ server on behalf of the client, and then transfers the data from the
+ remote server to itself, and then on to the client. The referral
+ mechanism's direct client connection to the remote server is often a
+ more efficient use of bandwidth, and does not require the local
+ server to impersonate the client when authenticating to the remote
+ server.
+
+2. Conventions used in this document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+ A home server, is an IMAP4 server that contains the user's inbox.
+
+ A remote server is a server that contains remote mailboxes.
+
+
+
+
+
+Gahrns Standards Track [Page 1]
+
+RFC 2221 IMAP4 Login Referrals October 1997
+
+
+ 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].
+
+3. Introduction and Overview
+
+ IMAP4 servers that support this extension MUST list the keyword
+ LOGIN-REFERRALS in their CAPABILITY response. No client action is
+ needed to invoke the LOGIN-REFERRALS capability in a server.
+
+ A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral
+ to a server that will return a referral. A client MUST NOT follow
+ more than 10 levels of referral without consulting the user.
+
+ A LOGIN-REFERRALS response code MUST contain as an argument a valid
+ IMAP server URL as defined in [IMAP-URL].
+
+ A home server referral consists of either a tagged NO or OK, or an
+ untagged BYE response that contains a LOGIN-REFERRALS response code.
+
+ Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server
+
+ NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a
+ client falling back to anonymous login.
+
+4. Home Server Referrals
+
+ A home server referral may be returned in response to an AUTHENTICATE
+ or LOGIN command, or it may appear in the connection startup banner.
+ If a server returns a home server referral in a tagged NO response,
+ that server does not contain any mailboxes that are accessible to the
+ user. If a server returns a home server referral in a tagged OK
+ response, it indicates that the user's personal mailboxes are
+ elsewhere, but the server contains public mailboxes which are
+ readable by the user. After receiving a home server referral, the
+ client can not make any assumptions as to whether this was a
+ permanent or temporary move of the user.
+
+4.1. LOGIN and AUTHENTICATE Referrals
+
+ An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a
+ home server referral if it wishes to direct the user to another IMAP4
+ server.
+
+ Example: C: A001 LOGIN MIKE PASSWORD
+ S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user
+ is invalid on this server. Try SERVER2.
+
+
+
+
+Gahrns Standards Track [Page 2]
+
+RFC 2221 IMAP4 Login Referrals October 1997
+
+
+ Example: C: A001 LOGIN MATTHEW PASSWORD
+ S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified
+ user's personal mailboxes located on Server2, but
+ public mailboxes are available.
+
+ Example: C: A001 AUTHENTICATE GSSAPI
+ <authentication exchange>
+ S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/]
+ Specified user is invalid on this server. Try
+ SERVER2.
+
+4.2. BYE at connection startup referral
+
+ An IMAP4 server MAY respond with an untagged BYE and a REFERRAL
+ response code that contains an IMAP URL to a home server if it is not
+ willing to accept connections and wishes to direct the client to
+ another IMAP4 server.
+
+ Example: S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not
+ accepting connections. Try SERVER2
+
+5. Formal Syntax
+
+ The following syntax specification uses the augmented Backus-Naur
+ Form (BNF) as described in [ABNF].
+
+ This amends the "resp_text_code" element of the IMAP4 grammar
+ described in [RFC-2060]
+
+ resp_text_code =/ "REFERRAL" SPACE <imapurl>
+ ; See [IMAP-URL] for definition of <imapurl>
+ ; See [RFC-2060] for base definition of resp_text_code
+
+6. Security Considerations
+
+ The IMAP4 login referral mechanism makes use of IMAP URLs, and as
+ such, have the same security considerations as general internet URLs
+ [RFC-1738], and in particular IMAP URLs [IMAP-URL].
+
+ A server MUST NOT give a login referral if authentication for that
+ user fails. This is to avoid revealing information about the user's
+ account to an unauthorized user.
+
+ With the LOGIN-REFERRALS capability, it is potentially easier to
+ write a rogue 'password catching' server that collects login data and
+ then refers the client to their actual IMAP4 server. Although
+ referrals reduce the effort to write such a server, the referral
+ response makes detection of the intrusion easier.
+
+
+
+Gahrns Standards Track [Page 3]
+
+RFC 2221 IMAP4 Login Referrals October 1997
+
+
+7. References
+
+ [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
+ 4rev1", RFC 2060, December 1996.
+
+ [IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
+ September 1997.
+
+ [RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+ [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for
+ Syntax Specifications: ABNF", Work in Progress.
+
+8. Acknowledgments
+
+ Many valuable suggestions were received from private discussions and
+ the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin,
+ Mark Keasling Chris Newman and Larry Osterman made significant
+ contributions to this document.
+
+9. Author's Address
+
+ Mike Gahrns
+ Microsoft
+ One Microsoft Way
+ Redmond, WA, 98072
+
+ Phone: (206) 936-9833
+ EMail: mikega@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns Standards Track [Page 4]
+
+RFC 2221 IMAP4 Login Referrals October 1997
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implmentation may be prepared, copied, published
+ andand distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gahrns Standards Track [Page 5]
+
+
+
Propchange: james/server/trunk/src/site/resources/rfclist/imap4/rfc2221.txt
------------------------------------------------------------------------------
svn:eol-style = native
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org