rfc5092.txt

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

      imap://<iserver>[/]

   This URL type is frequently used to describe a location of an IMAP
   server, both in referrals and in configuration.  It may optionally
   contain the <iuserinfo> component (see Sections 3 and 11).  A program
   interpreting this URL would issue the standard set of commands it
   uses to present a view of the content of the IMAP server, as visible
   to the user described by the "enc-user" part of the <iuserinfo>
   component, if the "enc-user" part is specified.

5.  Lists of Messages

   An IMAP URL referring to a list of messages has the following form:

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

   The <enc-mailbox> field is used as the argument to the IMAP4 "SELECT"
   or "EXAMINE" command.  Note that if unsafe or reserved characters
   such as " " (space), ";", or "?" are present in <enc-mailbox>, they
   MUST be percent-encoded as described in [URI-GEN].

   The <uidvalidity> field is optional.  If it is present, it MUST be
   the same as the value of IMAP4 UIDVALIDITY response code at the time
   the URL was created.  This MUST be used by the program interpreting
   the IMAP URL to determine if the URL is stale.  If the IMAP URL is
   stale, then the program should behave as if the corresponding mailbox
   doesn't exist.





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


   Note that the <uidvalidity> field is a modifier to the <enc-mailbox>,
   i.e., it is considered a part of the last "component" (as used in
   [URI-GEN]) of the <enc-mailbox>.  This is significant during relative
   URI resolution.

   The "?<enc-search>" field is optional.  If it is not present, the
   program interpreting the URL will present the entire content of the
   mailbox.

   If the "?<enc-search>" field is present, the program interpreting the
   URL should use the contents of this field as arguments following an
   IMAP4 SEARCH command.  These arguments are likely to contain unsafe
   characters such as " " (space) (which are likely to be present in the
   <enc-search>).  If unsafe characters are present, they MUST be
   percent-encoded as described in [URI-GEN].

   Note that quoted strings and non-synchronizing literals [LITERAL+]
   are allowed in the <enc-search> content; however, synchronizing
   literals are not allowed, as their presence would effectively mean
   that the agent interpreting IMAP URLs needs to parse an <enc-search>
   content, find all synchronizing literals, and perform proper command
   continuation request handling (see Sections 4.3 and 7 of [IMAP4]).

6.  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>][<ipartial>][<iurlauth>]

   The <enc-mailbox> and [uidvalidity] are as defined in Section 5
   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 Unique Identifier (UID), and it
   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 by using a "UID FETCH <uid>
   BODYSTRUCTURE" command and locating the appropriate part in the




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


   resulting BODYSTRUCTURE.  Note that unsafe characters in [isection]
   MUST be percent-encoded as described in [URI-GEN].

   The <ipartial> field is optional.  If present, it effectively appends
   "<<partial-range>>" to the end of the UID FETCH BODY.PEEK[<section>]
   command constructed as described in the previous paragraph.  In other
   words, it allows the client to request a byte range of the
   message/message part.

   The <iurlauth> field is described in detail in Section 6.1.

6.1.  URLAUTH Authorized URL

   URLAUTH authorized URLs are only supported by an IMAP server
   advertising the URLAUTH IMAP capability [URLAUTH].

6.1.1.  Concepts

6.1.1.1.  URLAUTH

   URLAUTH is a component, appended at the end of a URL, that conveys
   authorization to access the data addressed by that URL.  It contains
   an authorized access identifier, an authorization mechanism name, and
   an authorization token.  The authorization token is generated from
   the URL, the authorized access identifier, authorization mechanism
   name, and a mailbox access key.

      Note: This specification only allows for the URLAUTH component in
      IMAP URLs describing a message or its part.

6.1.1.2.  Mailbox Access Key

   The mailbox access key is an unpredictable, random string.  To ensure
   unpredictability, the random string with at least 128 bits of entropy
   is generated by software or hardware (not by the human user).

   Each user has a table of mailboxes and an associated mailbox access
   key for each mailbox.  Consequently, the mailbox access key is per-
   user and per-mailbox.  In other words, two users sharing the same
   mailbox each have a different mailbox access key for that mailbox,
   and each mailbox accessed by a single user also has a different
   mailbox access key.

6.1.1.3.  Authorized Access Identifier

   The authorized <access> identifier restricts use of the URLAUTH
   authorized URL to certain users authorized on the server, as
   described in Section 6.1.2.



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


6.1.1.4.  Authorization Mechanism

   The authorization mechanism is the algorithm by which the URLAUTH is
   generated and subsequently verified, using the mailbox access key.

6.1.1.5.  Authorization Token

   The authorization token is a deterministic string of at least 128
   bits that an entity with knowledge of the secret mailbox access key
   and URL authorization mechanism can use to verify the URL.

6.1.2.  URLAUTH Extensions to IMAP URL

   A specific message or message part IMAP URL can optionally contain
   ";EXPIRE=<datetime>" and/or ";URLAUTH=<access>:<mech>:<token>".

   When ";EXPIRE=<datetime>" is used, this indicates the latest date and
   time that the URL is valid.  After that date and time, the URL has
   expired and server implementations MUST reject the URL.  If
   ";EXPIRE=<datetime>" is not used, the URL has no expiration, but can
   still be revoked using the RESETKEY command [URLAUTH].

   The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>", and it
   MUST be at the end of the URL.  It is composed of three parts.  The
   <access> portion provides the authorized access identifiers that may
   constrain the operations and users that are permitted to use this
   URL.  The <mech> portion provides the authorization mechanism used by
   the IMAP server to generate the authorization token that follows.
   The <token> portion provides the authorization token, which can be
   generated using the GENURLAUTH command [URLAUTH].

   The "submit+" <access> identifier prefix, followed by a userid,
   indicates that only a userid authorized as a message submission
   entity on behalf of the specified userid is permitted to use this
   URL.  The IMAP server does not validate the specified userid but does
   validate that the IMAP session has an authorization identity that is
   authorized as a message submission entity.  The authorized message
   submission entity MUST validate the userid prior to contacting the
   IMAP server.

   The "user+" <access> identifier prefix, followed by a userid,
   indicates that use of this URL is limited to IMAP sessions that are
   logged in as the specified userid (that is, have authorization
   identity as that userid).

      Note: If a SASL mechanism that provides both authorization and
      authentication identifiers is used to authenticate to the IMAP
      server, the "user+" <access> identifier MUST match the



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


      authorization identifier.  If the SASL mechanism can't transport
      the authorization identifier, the "user+" <access> identifier MUST
      match the authorization identifier derived from the authentication
      identifier (see [SASL]).

   The "authuser" <access> identifier indicates that use of this URL is
   limited to authenticated IMAP sessions that are logged in as any
   non-anonymous user (that is, have authorization identity as a non-
   anonymous user) of that IMAP server.  To restate this: use of this
   type of URL is prohibited to anonymous IMAP sessions, i.e., any
   URLFETCH command containing this type of URL issued in an anonymous
   session MUST return NIL in the URLFETCH response.

   The "anonymous" <access> identifier indicates that use of this URL is
   not restricted by session authorization identity; that is, any IMAP
   session in authenticated or selected state (as defined in [IMAP4]),
   including anonymous sessions, may issue a URLFETCH [URLAUTH] using
   this URL.

   The authorization token is represented as an ASCII-encoded
   hexadecimal string, which is used to authorize the URL.  The length
   and the calculation of the authorization token depend upon the
   mechanism used, but in all cases, the authorization token is at least
   128 bits (and therefore at least 32 hexadecimal digits).

   Example:

      <imap://[e-mail]/INBOX/;uid=20/;section=1.2;urlauth=
      submit+fred:internal:91354a473744909de610943775f92038>

7.  Relative IMAP URLs

   Relative IMAP URLs are permitted and are resolved according to the
   rules defined in [URI-GEN].  In particular, in IMAP URLs parameters
   (such as ";uid=" or ";section=") are treated as part of the normal
   path with respect to relative URL resolution.

   [URI-GEN] defines four forms of relative URLs: <inetwork-path>,
   <iabsolute-path>, <irelative-path>, and <ipath-empty>.  Their syntax
   is defined in Section 11.

   A relative reference that begins with two slash characters is termed
   a network-path reference (<inetwork-path>); such references are
   rarely used, because in most cases they can be replaced with an
   equivalent absolute URL.  A relative reference that begins with a
   single slash character is termed an absolute-path reference
   (<iabsolute-path>; see also Section 7.1).  A relative reference that
   does not begin with a slash character is termed a relative-path



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


   reference (<irelative-path>; see also Section 7.2).  The final form
   is <ipath-empty>, which is "same-document reference" (see Section 4.4
   of [URI-GEN]).

   The following observations about relative URLs are important:

   The <iauth> grammar element (which is a part of <iuserinfo>, which
   is, in turn, a part of <iserver>; see Section 3) is considered part
   of the user name for purposes of resolving relative IMAP URLs.  This
   means that unless a new user name/server specification is included in
   the relative URL, the authentication mechanism is inherited from the
   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 that 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.

   If an IMAP server allows for mailbox names starting with "./" or
   "../", ending with "/." or "/..", or containing sequences "/../" or
   "/./", then such mailbox names MUST be percent-encoded as described
   in [URI-GEN].  Otherwise, they would be misinterpreted as dot-
   segments (see Section 3.3 of [URI-GEN]), which are processed
   specially during the relative path resolution process.

7.1.  absolute-path References

   A relative reference that begins with a single slash character is
   termed an absolute-path reference (see Section 4.2 of [URI-GEN]).  If
   an IMAP server permits mailbox names with a leading "/", then the
   leading "/" MUST be percent-encoded as described in [URI-GEN].
   Otherwise, the produced absolute-path reference URI will be
   misinterpreted as a network-path reference [URI-GEN] described by the
   <inetwork-path> non-terminal.

7.2.  relative-path References

   A relative reference that does not begin with a slash character is
   termed a relative-path reference [URI-GEN].  Implementations MUST NOT
   generate or accept relative-path IMAP references.

   See also Section 4.2 of [URI-GEN] for restrictions on relative-path
   references.




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


8.  Internationalization Considerations

   IMAP4, Section 5.1.3 [IMAP4] 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 [UTF-8].  Since 8-bit octets are not permitted in
   URLs, the UTF-8 octets are percent-encoded as required by the URL
   specification [URI-GEN], Section 2.1.  Sample code is included in
   Appendix A to demonstrate this conversion.

   IMAP user names are UTF-8 strings and MUST be percent-encoded as
   required by the URL specification [URI-GEN], Section 2.1.

   Also note that IMAP SEARCH criteria can contain non-US-ASCII
   characters.  8-bit octets in those strings MUST be percent-encoded as
   required by the URL specification [URI-GEN], Section 2.1.

9.  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.example.org/gray-council;UIDVALIDITY=385759045/;
      UID=20/;PARTIAL=0.1024>

   may result in the following client commands and server responses:

      <connect to minbari.example.org, port 143>
      S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=ANONYMOUS] Welcome
      C: A001 AUTHENTICATE ANONYMOUS
      S: +
      C: c2hlcmlkYW5AYmFieWxvbjUuZXhhbXBsZS5vcmc=
      S: A001 OK Welcome [e-mail]
      C: A002 SELECT gray-council
      <client verifies the UIDVALIDITY matches>