;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
S: a777 OK GENURLAUTH completed
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://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred:internal
:91354a473744909de610943775f92038"
S: * URLFETCH "imap://joe@example.com/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)
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
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
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]
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: (206) 543-5762
EMail: MRC@CAC.Washington.EDU
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
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).