rfc5092.txt

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

Network Working Group                                   A. Melnikov, Ed.
Request for Comments: 5092                                    Isode Ltd.
Obsoletes: 2192                                                C. Newman
Updates: 4467                                           Sun Microsystems
Category: Standards Track                                  November 2007


                            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 (RFC 3501) 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.

   This document obsoletes RFC 2192.  It also updates RFC 4467.

























Melnikov & Newman           Standards Track                     [Page 1]

RFC 5092                    IMAP URL Scheme                November 2007


Table of Contents

   1. Introduction ....................................................2
   2. Conventions Used in This Document ...............................3
   3. IMAP userinfo Component (iuserinfo) .............................4
      3.1. IMAP Mailbox Naming Scope ..................................4
      3.2. IMAP User Name and Authentication Mechanism ................4
      3.3. Limitations of enc-user ....................................6
   4. IMAP Server .....................................................7
   5. Lists of Messages ...............................................7
   6. A Specific Message or Message Part ..............................8
      6.1. URLAUTH Authorized URL .....................................9
           6.1.1. Concepts ............................................9
                  6.1.1.1. URLAUTH ....................................9
                  6.1.1.2. Mailbox Access Key .........................9
                  6.1.1.3. Authorized Access Identifier ...............9
                  6.1.1.4. Authorization Mechanism ...................10
                  6.1.1.5. Authorization Token .......................10
           6.1.2. URLAUTH Extensions to IMAP URL .....................10
   7. Relative IMAP URLs .............................................11
      7.1. absolute-path References ..................................12
      7.2. relative-path References ..................................12
   8. Internationalization Considerations ............................13
   9. Examples .......................................................13
      9.1. Examples of Relative URLs .................................16
   10. Security Considerations .......................................16
      10.1. Security Considerations Specific to URLAUTH Authorized
            URL ......................................................17
   11. ABNF for IMAP URL Scheme ......................................17
   12. IANA Considerations ...........................................21
      12.1. IANA Registration of imap: URI Scheme ....................21
   13. References ....................................................22
      13.1. Normative References .....................................22
      13.2. Informative References ...................................23
   Appendix A. Sample Code............................................24
   Appendix B. List of Changes since RFC 2192.........................30
   Appendix C. List of Changes since RFC 4467.........................31
   Appendix D. Acknowledgments........................................31

1.  Introduction

   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 over TCP.

   The IMAP URL follows the common Internet scheme syntax as defined in
   [URI-GEN].  If :<port> is omitted, the port defaults to 143 (as
   defined in Section 2.1 of [IMAP4]).



Melnikov & Newman           Standards Track                     [Page 2]

RFC 5092                    IMAP URL Scheme                November 2007


   An absolute IMAP URL takes one of the following forms:

      imap://<iserver>[/]

      imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]

      imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
       [<isection>][<ipartial>][<iurlauth>]

   The first form is used to refer to an IMAP server (see Section 4),
   the second form refers to the contents of a mailbox or a set of
   messages resulting from a search (see Section 5), and the final form
   refers to a specific message or message part, and possibly a byte
   range in that part (see Section 6).  If [URLAUTH] extension is
   supported, then the final form can have the <iurlauth> component (see
   Section 6.1 for more details).

   The <iserver> component common to all types of absolute IMAP URLs has
   the following syntax expressed in ABNF [ABNF]:

      [iuserinfo "@"] host [ ":" port ]

   The <iserver> component is the same as "authority" defined in
   [URI-GEN].  The syntax and uses of the <iuserinfo> ("IMAP userinfo
   component") are described in detail in Section 3.  The syntax of
   <host> and <port> is described in [URI-GEN].

2.  Conventions Used in This Document

   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 [KEYWORDS].

   This document references many productions from [URI-GEN].  When the
   document needs to emphasize IMAP URI-specific differences from [URI-
   GEN] (i.e., for parts of IMAP URIs that have more restricted syntax
   than generic URIs), it uses a non-terminal i<foo> to define an IMAP-
   specific version of the non-terminal <foo> from [URI-GEN].

   Note that the ABNF syntax shown in Section 11 is normative.  Sections
   2-6 may use a less formal syntax that does not necessarily match the
   normative ABNF shown in Section 11.  If there are any differences
   between the syntax shown in Sections 2-6 and Section 11, then the
   syntax shown in Section 11 must be treated as authoritative.  Non-
   syntax requirements included in Sections 2-6 are, of course,
   normative.





Melnikov & Newman           Standards Track                     [Page 3]

RFC 5092                    IMAP URL Scheme                November 2007


3.  IMAP userinfo Component (iuserinfo)

   The <iuserinfo> component conforms to the generic syntax of
   <userinfo> defined in [URI-GEN].  It has the following syntax
   expressed in ABNF [ABNF]:

      enc-user [iauth] / [enc-user] iauth

   The meaning of the different parts is described in subsections of
   this section.

3.1.  IMAP Mailbox Naming Scope

   The "enc-user" part of the "iuserinfo" component, if present, denotes
   mailbox naming scope.  If it is absent, the IMAP URL can only
   reference mailboxes with globally unique names, i.e., mailboxes with
   names that don't change depending on the user the client
   authenticated as to the IMAP server.  Note that not all IMAP
   implementations support globally unique names.

   For example, a personal mailbox described by the following URL
   <imap://[e-mail]/INBOX> is most likely different from a
   personal mailbox described by <imap://[e-mail]/INBOX>, even
   though both URLs use the same mailbox name.

3.2.  IMAP User Name and Authentication Mechanism

   The userinfo component (see [URI-GEN]) of an IMAP URI may contain an
   IMAP user name (a.k.a. authorization identity [SASL], "enc-user")
   and/or an authentication mechanism. (Note that the "enc-user" also
   defines a mailbox naming scope as described in Section 3.1).  The
   IMAP user name and the authentication mechanism are used in the
   "LOGIN" or "AUTHENTICATE" commands after making the connection to the
   IMAP server.

   If no user name and no authentication mechanism are supplied, the
   client MUST authenticate as anonymous to the server.  If the server
   advertises AUTH=ANONYMOUS IMAP capability, the client MUST use the
   AUTHENTICATE command with ANONYMOUS [ANONYMOUS] SASL mechanism.  If
   SASL ANONYMOUS is not available, the (case-insensitive) user name
   "anonymous" is used with the "LOGIN" command and the Internet email
   address of the end user accessing the resource is supplied as the
   password.  The latter option is given in order to provide for
   interoperability with deployed servers.

   Note that, as described in RFC 3501, the "LOGIN" command MUST NOT be
   used when the IMAP server advertises the LOGINDISABLED capability.




Melnikov & Newman           Standards Track                     [Page 4]

RFC 5092                    IMAP URL Scheme                November 2007


   An authentication mechanism (as used by the IMAP AUTHENTICATE
   command) can be expressed by adding ";AUTH=<enc-auth-type>" to the
   end of the user name in an IMAP URL.  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 MUST be obtained
   from the mechanism or requested from the user/configuration as
   appropriate.

   The string ";AUTH=*" indicates that the client SHOULD select an
   appropriate authentication mechanism.  (Though the '*' character in
   this usage is not strictly a delimiter, it is being treated like a
   sub-delim [URI-GEN] in this instance.  It MUST NOT be percent-encoded
   in this usage, as ";AUTH=%2A" will not match this production.)  It
   MAY use any mechanism listed in the response to the CAPABILITY
   command (or CAPABILITY response code) 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.
   The behavior prescribed in this section allows a URL that 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.

   Clients must take care when resolving a URL that requires or requests
   any sort of authentication, since URLs can easily come from untrusted
   sources.  Supplying authentication credentials to the wrong server
   may compromise the security of the user's account; therefore, the
   program resolving the URL should meet at least one of the following
   criteria in this case:

   1) The URL comes from a trusted source, such as a referral server
      that 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, a company example.com may have a
      site policy to trust all IMAP server names ending in example.com,
      whereas such a policy would be unwise for example.edu where random
      students can set up IMAP servers.

   3) The user confirms that connecting to that domain name with the
      specified credentials and/or mechanism is permitted.  For example,
      when using "LOGIN" or SASL PLAIN with Transport Layer Security



Melnikov & Newman           Standards Track                     [Page 5]

RFC 5092                    IMAP URL Scheme                November 2007


      (TLS), the IMAP URL client presents a dialog box "Is it OK to send
      your password to server "example.com"?  Please be aware the owners
      of example.com will be able to reuse your password to connect to
      other servers on your behalf".

   4) A mechanism is used that validates the server before passing
      potentially compromising client credentials.  For example, a site
      has a designated TLS certificate used to certify site-trusted IMAP
      server certificates, and this has been configured explicitly into
      the IMAP URL client.  Another example is use of a Simple
      Authentication and Security Layer (SASL) mechanism such as
      DIGEST-MD5 [DIGEST-MD5], which supports mutual authentication.

   5) An authentication mechanism is used that will not reveal any
      information to the server that could be used to compromise future
      connections.  Examples are SASL ANONYMOUS [ANONYMOUS] or GSSAPI
      [GSSAPI].

   URLs that do not include a user name but include an authentication
   mechanism (";AUTH=<mech>") must be treated with extra care, since for
   some <mech>s 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 plaintext password as a
   fallback with ";AUTH=*" unless the connection has strong encryption.

   A program interpreting IMAP URLs MAY cache open connections to an
   IMAP server for later reuse.  If a URL contains a user name, only
   connections authenticated as that user may be reused.  If a URL does
   not contain a user name or authentication mechanism, then only an
   anonymous connection may be reused.

   Note that if unsafe or reserved characters such as " " (space) or ";"
   are present in the user name or authentication mechanism, they MUST
   be percent-encoded as described in [URI-GEN].

3.3.  Limitations of enc-user

   As per Sections 3.1 and 3.2 of this document, the IMAP URI enc-user
   has two purposes:

      1) It provides context for user-specific mailbox paths such as
         "INBOX" (Section 3.1).

      2) It specifies that resolution of the URL requires logging in as
         that user and limits use of that URL to only that user (Section
         3.2).




Melnikov & Newman           Standards Track                     [Page 6]

RFC 5092                    IMAP URL Scheme                November 2007


   An obvious limitation of using the same field for both purposes is
   that the URL can be resolved only by the mailbox owner.  In order to
   avoid this restriction, implementations should use globally unique
   mailbox names (see Section 3.1) whenever possible.

      Note: There is currently no general way in IMAP of learning a
      globally unique name for a mailbox.  However, by looking at the
      NAMESPACE [NAMESPACE] command result, it is possible to determine
      whether or not a mailbox name is globally unique.

   The URLAUTH component overrides the second purpose of the enc-user in
   the IMAP URI and by default permits the URI to be resolved by any
   user permitted by the <access> identifier.  URLAUTH and <access>
   identifier are described in Section 6.1.

4.  IMAP Server

   An IMAP URL referring to an IMAP server has the following form: