rfc4467.txt

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

BASE.7.4.URLFETCH.  URLFETCH Response

   Contents:   One or more URL/nstring pairs

   The URLFETCH response returns the message text data associated with
   one or more IMAP URLs, as described in [IMAPURL] and extended by this
   document.  This response occurs as the result of a URLFETCH command.

   The returned data string is NIL if the URL is invalid for any reason
   (including validation failure).  If the URL is valid, but the IMAP
   fetch of the body part returned NIL (this should not happen), the
   returned data string should be the empty string ("") and not NIL.

      Note: This command does not require that the URL refer to the
      selected mailbox; nor does it require that any mailbox be
      selected.  It also does not in any way interfere with any selected
      mailbox.

   Example:

      C: a002 URLFETCH "imap://[e-mail]/INBOX/;uid=20/
         ;section=1.2;urlauth=submit+fred:internal
         :91354a473744909de610943775f92038"
      S: * URLFETCH "imap://[e-mail]/INBOX/;uid=20/;section=1.2
         ;urlauth=submit+fred:internal
         :91354a473744909de610943775f92038" {28}
      S: Si vis pacem, para bellum.
      S:
      S: a002 OK URLFETCH completed

9.  Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [ABNF].

   The following modifications are made to the Formal Syntax in [IMAP]:

resetkey        = "RESETKEY" [SP mailbox *(SP mechanism)]

capability      =/ "URLAUTH"

command-auth    =/ resetkey / genurlauth / urlfetch

resp-text-code  =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])

genurlauth      = "GENURLAUTH" 1*(SP url-rump SP mechanism)

genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url-full)



Crispin                     Standards Track                    [Page 13]

RFC 4467                IMAP - URLAUTH Extension                May 2006


url-full        = astring
                     ; contains authimapurlfull as defined below

url-rump        = astring
                     ; contains authimapurlrump as defined below

urlfetch        = "URLFETCH" 1*(SP url-full)

urlfetch-data   = "*" SP "URLFETCH" 1*(SP url-full SP nstring)

   The following extensions are made to the Formal Syntax in [IMAPURL]:

authimapurl     = "imap://" enc-user [iauth] "@" hostport "/"
                     imessagepart
                     ; replaces "imapurl" and "iserver" rules for
                     ; URLAUTH authorized URLs

authimapurlfull = authimapurl iurlauth

authimapurlrump = authimapurl iurlauth-rump

enc-urlauth     = 32*HEXDIG

enc-user        = 1*achar
                     ; same as "enc_user" in RFC 2192

iurlauth        = iurlauth-rump ":" mechanism ":" enc-urlauth

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

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

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

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












Crispin                     Standards Track                    [Page 14]

RFC 4467                IMAP - URLAUTH Extension                May 2006


10.  Security Considerations

   Security considerations are discussed throughout this memo.

   The mailbox access key SHOULD have at least 128 bits of entropy
   (refer to [RANDOM] for more details) and MUST be unpredictable.

   The server implementation of the INTERNAL mechanism SHOULD consider
   the possibility of needing to change the token generation algorithm,
   and SHOULD incorporate some means of identifying the token generation
   algorithm within the token.

   The URLMECH status response code may expose sensitive data in the
   mechanism-specific data for mechanisms other than INTERNAL.  A server
   implementation MUST implement a configuration that will not return a
   URLMECH status response code unless some mechanism is provided that
   protects the session from snooping, such as a TLS or SASL security
   layer that provides confidentiality protection.

   The calculation of an authorization token with a "plausible" key if
   the mailbox can not be identified is necessary to avoid attacks in
   which the server is probed to see if a particular mailbox exists on
   the server by measuring the amount of time taken to reject a known
   bad name versus some other name.

   To protect against a computational denial-of-service attack, a server
   MAY impose progressively longer delays on multiple URL requests that
   fail validation.

   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.  Many IMAP servers do not
   permit anonymous access; in this case, the "anonymous" access
   identifier is equivalent to "authuser", but this MUST NOT be relied
   upon.

   Although this specification does not prohibit the theoretical
   capability to generate a URL with a server component other than the
   logged in userid and server, this capability should only be provided





Crispin                     Standards Track                    [Page 15]

RFC 4467                IMAP - URLAUTH Extension                May 2006


   when the logged in userid/server has been authorized as equivalent to
   the server component userid/server, or otherwise has access to that
   userid/server mailbox access key table.

11.  IANA Considerations

   This document constitutes registration of the URLAUTH capability in
   the imap4-capabilities registry.

   URLAUTH authorization mechanisms are registered by publishing a
   standards track or IESG-approved experimental RFC.  The registry is
   currently located at:

http://www.iana.org/assignments/urlauth-authorization-mechanism-registry

   This registry is case-insensitive.

   This document constitutes registration of the INTERNAL URLAUTH
   authorization mechanism.

   IMAP URLAUTH Authorization Mechanism Registry

      Mechanism Name           Reference
      --------------           ---------
      INTERNAL                 [RFC4467]


























Crispin                     Standards Track                    [Page 16]

RFC 4467                IMAP - URLAUTH Extension                May 2006


12.  Normative References

   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [BURL]     Newman, C., "Message Submission BURL Extension", RFC 4468,
              May 2006.

   [DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, July 2002.

   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 3501, March 2003.

   [IMAPURL]  Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

13.  Informative References

   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

   [RANDOM]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              June 2005.

Author's Address

   Mark R. Crispin
   Networks and Distributed Computing
   University of Washington
   4545 15th Avenue NE
   Seattle, WA  98105-4527

   Phone: [phone]
   EMail: [e-mail]












Crispin                     Standards Track                    [Page 17]

RFC 4467                IMAP - URLAUTH Extension                May 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Crispin                     Standards Track                    [Page 18]