rfc5092.txt

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

      C: A003 UID FETCH 20 BODY.PEEK[]<0.1024>

   The URL:

      <imap://psicorp.example.org/~peter/%E6%97%A5%E6%9C%AC%E8%AA%9E/
      %E5%8F%B0%E5%8C%97>



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


   may result in the following client commands:

      <connect to psicorp.example.org, port 143>
      S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=CRAM-MD5] Welcome
      C: A001 LOGIN ANONYMOUS [e-mail]
      C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw-
      <commands the client uses for viewing the contents of
       the mailbox>

   The URL:

      <imap://;AUTH=[e-mail]/gray-council/;uid=20/
      ;section=1.2>

   may result in the following client commands:

      <connect to minbari.example.org, port 143>
      S: * OK Greetings
      C: A000 CAPABILITY
      S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
      S: A000 OK
      C: A001 AUTHENTICATE GSSAPI
      <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-Location)])
      <Client looks for 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.example.org/gray%20council?
      SUBJECT%20shadows>








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


   could result in the following:

      <connect to minbari.example.org, port 143>
      S: * OK Welcome
      C: A001 CAPABILITY
      S: * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5
      S: A001 OK
      C: A002 AUTHENTICATE DIGEST-MD5
      <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
      ...

   In the example above, the client has implementation-dependent
   choices.  The authentication mechanism could be anything, including
   PREAUTH.  The final FETCH command could fetch more or less
   information about the messages, depending on what it wishes to
   display to the user.

   The URL:

      <imap://john;AUTH=*@minbari.example.org/babylon5/personel?
      charset%20UTF-8%20SUBJECT%20%7B14+%7D%0D%0A%D0%98%D0%B2%
      D0%B0%D0%BD%D0%BE%D0%B2%D0%B0>

   shows that 8-bit data can be sent using non-synchronizing literals
   [LITERAL+].  This could result in the following:

      <connect to minbari.example.org, port 143>
      S: * OK Hi there
      C: A001 CAPABILITY
      S: * CAPABILITY IMAP4rev1 LITERAL+ AUTH=DIGEST-MD5
      S: A001 OK
      C: A002 AUTHENTICATE DIGEST-MD5
      <authentication exchange>
      S: A002 OK user john authenticated
      C: A003 SELECT babylon5/personel
      ...
      C: A004 SEARCH CHARSET UTF-8 SUBJECT {14+}
      C: XXXXXXXXXXXXXX
      S: * SEARCH 7 10 12
      S: A004 OK SEARCH completed
      C: A005 FETCH 7,10,12 ALL



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


      ...

   where XXXXXXXXXXXXXX is 14 bytes of UTF-8 encoded data as specified
   in the URL above.

9.1.  Examples of Relative URLs

   The following absolute-path reference

      </foo/;UID=20/..>

   is the same as

      </foo>

   That is, both of them reference the mailbox "foo" located on the IMAP
   server described by the corresponding Base URI.

   The following relative-path reference

      <;UID=20>

   references a message with UID in the mailbox specified by the Base
   URI.

   The following edge case example demonstrates that the ;UIDVALIDITY=
   modifier is a part of the mailbox name as far as relative URI
   resolution is concerned:

      <..;UIDVALIDITY=385759045/;UID=20>

   In this example, ".." is not a dot-segment [URI-GEN].

10.  Security Considerations

   Security considerations discussed in the IMAP specification [IMAP4]
   and the URI specification [URI-GEN] are relevant.  Security
   considerations related to authenticated URLs are discussed in Section
   3.2 of this document.

   Many email clients store the plaintext 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.

   Clients resolving IMAP URLs that wish to achieve data confidentiality
   and/or integrity SHOULD use the STARTTLS command (if supported by the




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


   server) before starting authentication, or use a SASL mechanism, such
   as GSSAPI, that provides a confidentiality security layer.

10.1.  Security Consideration Specific to URLAUTH Authorized URL

   The "user+<userid>" <access> identifier limits resolution of that URL
   to a particular userid, whereas the "submit+<userid>" <access>
   identifier is more general and simply requires that the session be
   authorized by a user that has been granted a "submit" role within the
   authentication system.  Use of either of these mechanisms limits the
   scope of the URL.  An attacker who cannot authenticate using the
   appropriate credentials cannot make use of the URL.

   The "authuser" and "anonymous" <access> identifiers do not have this
   level of protection.  These access identifiers are primarily useful
   for public export of data from an IMAP server, without requiring that
   it be copied to a web or anonymous FTP server.

   The decision to use the "authuser" <access> identifier should be made
   with caution.  An "authuser" <access> identifier can be used by any
   authorized user of the IMAP server; therefore, use of this access
   identifier should be limited to content that may be disclosed to any
   authorized user of the IMAP server.

   The decision to use the "anonymous" <access> identifier should be
   made with extreme caution.  An "anonymous" <access> identifier can be
   used by anyone; therefore, use of this access identifier should be
   limited to content that may be disclosed to anyone.

11.  ABNF for IMAP URL Scheme

   Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
   in Section 9 of [IMAP4].  Elements not defined here can be found in
   [ABNF], [IMAP4], [IMAPABNF], or [URI-GEN].  Strings are not case
   sensitive, and free insertion of linear white space is not permitted.

   sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
                   "*" / "+" / ","
                      ;; Same as [URI-GEN] sub-delims,
                      ;; but without ";", "&" and "=".

   uchar            = unreserved / sub-delims-sh / pct-encoded

   achar            = uchar / "&" / "="
                      ;; Same as [URI-GEN] 'unreserved / sub-delims /
                      ;; pct-encoded', but ";" is disallowed.

   bchar            = achar / ":" / "@" / "/"



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


   enc-auth-type    = 1*achar
                   ; %-encoded version of [IMAP4] "auth-type"

   enc-mailbox      = 1*bchar
                  ; %-encoded version of [IMAP4] "mailbox"

   enc-search       = 1*bchar
                           ; %-encoded version of [IMAPABNF]
                           ; "search-program".  Note that IMAP4
                           ; literals may not be used in
                           ; a "search-program", i.e., only
                           ; quoted or non-synchronizing
                           ; literals (if the server supports
                           ; LITERAL+ [LITERAL+]) are allowed.

   enc-section      = 1*bchar
                  ; %-encoded version of [IMAP4] "section-spec"

   enc-user         = 1*achar
                  ; %-encoded version of [IMAP4] authorization
                  ; identity or "userid".

   imapurl          = "imap://" iserver ipath-query
               ; Defines an absolute IMAP URL

   ipath-query      = ["/" [ icommand ]]
                    ; Corresponds to "path-abempty [ "?" query ]"
                    ; in [URI-GEN]

   Generic syntax for relative URLs is defined in Section 4.2 of
   [URI-GEN].  For ease of implementation, the relative IMAP URL syntax
   is defined below:

   imapurl-rel     = inetwork-path

                     / iabsolute-path
                     / irelative-path
                     / ipath-empty

   inetwork-path   = "//" iserver ipath-query
               ; Corresponds to '"//" authority path-abempty
               ; [ "?" query ]' in [URI-GEN]

   iabsolute-path  = "/" [ icommand ]
               ; icommand, if present, MUST NOT start with '/'.
               ;
               ; Corresponds to 'path-absolute [ "?" query ]'
               ; in [URI-GEN]



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


   irelative-path  = imessagelist /
                     imsg-or-part
               ; Corresponds to 'path-noscheme [ "?" query ]'
               ; in [URI-GEN]

   imsg-or-part    = ( imailbox-ref "/" iuid-only ["/" isection-only]
                       ["/" ipartial-only] ) /
                     ( iuid-only ["/" isection-only]
                       ["/" ipartial-only] ) /
                     ( isection-only ["/" ipartial-only] ) /
                     ipartial-only

   ipath-empty     = 0<pchar>
                    ; Zero characters.
                    ; The same-document reference.

   The following three rules are only used in the presence of the IMAP
   [URLAUTH] extension:

   authimapurl     = "imap://" iserver "/" imessagepart
                     ; Same as "imapurl" when "[icommand]" is
                     ; "imessagepart"

   authimapurlfull = authimapurl iurlauth
                     ; Same as "imapurl" when "[icommand]" is
                     ; "imessagepart iurlauth"

   authimapurlrump = authimapurl iurlauth-rump


   enc-urlauth     = 32*HEXDIG

   iurlauth        = iurlauth-rump iua-verifier

   iua-verifier    = ":" uauth-mechanism ":" enc-urlauth

   iurlauth-rump   = [expire] ";URLAUTH=" access

   access          = ("submit+" enc-user) / ("user+" enc-user) /
                       "authuser" / "anonymous"

   expire          = ";EXPIRE=" date-time
                         ; date-time is defined in [DATETIME]

   uauth-mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
                        ; Case-insensitive.
                        ; New mechanisms MUST be registered with IANA.




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


   iauth            = ";AUTH=" ( "*" / enc-auth-type )

   icommand         = imessagelist /
                      imessagepart [iurlauth]

   imailbox-ref     = enc-mailbox [uidvalidity]

   imessagelist     = imailbox-ref [ "?" enc-search ]
                  ; "enc-search" is [URI-GEN] "query".