--- /dev/null
+
+
+
+
+
+
+Network Working Group P. Hoffman
+Request for Comments: 2368 Internet Mail Consortium
+Updates: 1738, 1808 L. Masinter
+Category: Standards Track Xerox Corporation
+ J. Zawinski
+ Netscape Communications
+ July 1998
+
+
+ The mailto 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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ This document defines the format of Uniform Resource Locators (URL)
+ for designating electronic mail addresses. It is one of a suite of
+ documents which replace RFC 1738, 'Uniform Resource Locators', and
+ RFC 1808, 'Relative Uniform Resource Locators'. The syntax of
+ 'mailto' URLs from RFC 1738 is extended to allow creation of more RFC
+ 822 messages by allowing the URL to express additional header and
+ body fields.
+
+1. Introduction
+
+ The mailto URL scheme is used to designate the Internet mailing
+ address of an individual or service. In its simplest form, a mailto
+ URL contains an Internet mail address.
+
+ For greater functionality, because interaction with some resources
+ may require message headers or message bodies to be specified as well
+ as the mail address, the mailto URL scheme is extended to allow
+ setting mail header fields and the message body.
+
+2. Syntax of a mailto URL
+
+ Following the syntax conventions of RFC 1738 [RFC1738], a "mailto"
+ URL has the form:
+
+
+
+Hoffman, et. al. Standards Track [Page 1]
+
+RFC 2368 The mailto URL scheme July 1998
+
+
+ mailtoURL = "mailto:" [ to ] [ headers ]
+ to = #mailbox
+ headers = "?" header *( "&" header )
+ header = hname "=" hvalue
+ hname = *urlc
+ hvalue = *urlc
+
+ "#mailbox" is as specified in RFC 822 [RFC822]. This means that it
+ consists of zero or more comma-separated mail addresses, possibly
+ including "phrase" and "comment" components. Note that all URL
+ reserved characters in "to" must be encoded: in particular,
+ parentheses, commas, and the percent sign ("%"), which commonly occur
+ in the "mailbox" syntax.
+
+ "hname" and "hvalue" are encodings of an RFC 822 header name and
+ value, respectively. As with "to", all URL reserved characters must
+ be encoded.
+
+ The special hname "body" indicates that the associated hvalue is the
+ body of the message. The "body" hname should contain the content for
+ the first text/plain body part of the message. The mailto URL is
+ primarily intended for generation of short text messages that are
+ actually the content of automatic processing (such as "subscribe"
+ messages for mailing lists), not general MIME bodies.
+
+ Within mailto URLs, the characters "?", "=", "&" are reserved.
+
+ Because the "&" (ampersand) character is reserved in HTML, any mailto
+ URL which contains an ampersand must be spelled differently in HTML
+ than in other contexts. A mailto URL which appears in an HTML
+ document must use "&" instead of "&".
+
+ Also note that it is legal to specify both "to" and an "hname" whose
+ value is "to". That is,
+
+ mailto:addr1%2C%20addr2
+
+ is equivalent to
+
+ mailto:?to=addr1%2C%20addr2
+
+ is equivalent to
+
+ mailto:addr1?to=addr2
+
+ 8-bit characters in mailto URLs are forbidden. MIME encoded words (as
+ defined in [RFC2047]) are permitted in header values, but not for any
+ part of a "body" hname.
+
+
+
+Hoffman, et. al. Standards Track [Page 2]
+
+RFC 2368 The mailto URL scheme July 1998
+
+
+3. Semantics and operations
+
+ A mailto URL designates an "internet resource", which is the mailbox
+ specified in the address. When additional headers are supplied, the
+ resource designated is the same address, but with an additional
+ profile for accessing the resource. While there are Internet
+ resources that can only be accessed via electronic mail, the mailto
+ URL is not intended as a way of retrieving such objects
+ automatically.
+
+ In current practice, resolving URLs such as those in the "http"
+ scheme causes an immediate interaction between client software and a
+ host running an interactive server. The "mailto" URL has unusual
+ semantics because resolving such a URL does not cause an immediate
+ interaction. Instead, the client creates a message to the designated
+ address with the various header fields set as default. The user can
+ edit the message, send this message unedited, or choose not to send
+ the message. The operation of how any URL scheme is resolved is not
+ mandated by the URL specifications.
+
+4. Unsafe headers
+
+ The user agent interpreting a mailto URL SHOULD choose not to create
+ a message if any of the headers are considered dangerous; it may also
+ choose to create a message with only a subset of the headers given in
+ the URL. Only the Subject, Keywords, and Body headers are believed
+ to be both safe and useful.
+
+ The creator of a mailto URL cannot expect the resolver of a URL to
+ understand more than the "subject" and "body" headers. Clients that
+ resolve mailto URLs into mail messages should be able to correctly
+ create RFC 822-compliant mail messages using the "subject" and "body"
+ headers.
+
+5. Encoding
+
+ RFC 1738 requires that many characters in URLs be encoded. This
+ affects the mailto scheme for some common characters that might
+ appear in addresses, headers or message contents. One such character
+ is space (" ", ASCII hex 20). Note the examples above that use "%20"
+ for space in the message body. Also note that line breaks in the
+ body of a message MUST be encoded with "%0D%0A".
+
+ People creating mailto URLs must be careful to encode any reserved
+ characters that are used in the URLs so that properly-written URL
+ interpreters can read them. Also, client software that reads URLs
+ must be careful to decode strings before creating the mail message so
+
+
+
+
+Hoffman, et. al. Standards Track [Page 3]
+
+RFC 2368 The mailto URL scheme July 1998
+
+
+ that the mail messages appear in a form that the recipient will
+ understand. These strings should be decoded before showing the user
+ the message.
+
+ The mailto URL scheme is limited in that it does not provide for
+ substitution of variables. Thus, a message body that must include a
+ user's email address can not be encoded using the mailto URL. This
+ limitation also prevents mailto URLs that are signed with public keys
+ and other such variable information.
+
+6. Examples
+
+ URLs for an ordinary individual mailing address:
+
+ <mailto:chris@example.com>
+
+ A URL for a mail response system that requires the name of the file
+ in the subject:
+
+ <mailto:infobot@example.com?subject=current-issue>
+
+ A mail response system that requires a "send" request in the body:
+
+ <mailto:infobot@example.com?body=send%20current-issue>
+
+ A similar URL could have two lines with different "send" requests (in
+ this case, "send current-issue" and, on the next line, "send index".)
+
+ <mailto:infobot@example.com?body=send%20current-
+ issue%0D%0Asend%20index>
+
+ An interesting use of your mailto URL is when browsing archives of
+ messages. Each browsed message might contain a mailto URL like:
+
+ <mailto:foobar@example.com?In-Reply-
+ To=%3c3469A91.D10AF4C@example.com>
+
+ A request to subscribe to a mailing list:
+
+ <mailto:majordomo@example.com?body=subscribe%20bamboo-l>
+
+ A URL for a single user which includes a CC of another user:
+
+ <mailto:joe@example.com?cc=bob@example.com&body=hello>
+
+ Another way of expressing the same thing:
+
+ <mailto:?to=joe@example.com&cc=bob@example.com&body=hello>
+
+
+
+Hoffman, et. al. Standards Track [Page 4]
+
+RFC 2368 The mailto URL scheme July 1998
+
+
+ Note the use of the "&" reserved character, above. The following
+ example, by using "?" twice, is incorrect:
+
+ <mailto:joe@example.com?cc=bob@example.com?body=hello> ; WRONG!
+
+ According to RFC 822, the characters "?", "&", and even "%" may occur
+ in addr-specs. The fact that they are reserved characters in this URL
+ scheme is not a problem: those characters may appear in mailto URLs,
+ they just may not appear in unencoded form. The standard URL encoding
+ mechanisms ("%" followed by a two-digit hex number) must be used in
+ certain cases.
+
+ To indicate the address "gorby%kremvax@example.com" one would do:
+
+ <mailto:gorby%25kremvax@example.com>
+
+ To indicate the address "unlikely?address@example.com", and include
+ another header, one would do:
+
+ <mailto:unlikely%3Faddress@example.com?blat=foop>
+
+ As described above, the "&" (ampersand) character is reserved in HTML
+ and must be replacded with "&". Thus, a complex URL that has
+ internal ampersands might look like:
+
+ Click
+ <a href="mailto:?to=joe@xyz.com&cc=bob@xyz.com&body=hello">
+ mailto:?to=joe@xyz.com&cc=bob@xyz.com&body=hello</a> to
+ send a greeting message to <i>Joe and Bob</i>.
+
+7. Security Considerations
+
+ The mailto scheme can be used to send a message from one user to
+ another, and thus can introduce many security concerns. Mail messages
+ can be logged at the originating site, the recipient site, and
+ intermediary sites along the delivery path. If the messages are not
+ encoded, they can also be read at any of those sites.
+
+ A mailto URL gives a template for a message that can be sent by mail
+ client software. The contents of that template may be opaque or
+ difficult to read by the user at the time of specifying the URL.
+ Thus, a mail client should never send a message based on a mailto URL
+ without first showing the user the full message that will be sent
+ (including all headers that were specified by the mailto URL), fully
+ decoded, and asking the user for approval to send the message as
+ electronic mail. The mail client should also make it clear that the
+ user is about to send an electronic mail message, since the user may
+ not be aware that this is the result of a mailto URL.
+
+
+
+Hoffman, et. al. Standards Track [Page 5]
+
+RFC 2368 The mailto URL scheme July 1998
+
+
+ A mail client should never send anything without complete disclosure
+ to the user of what is will be sent; it should disclose not only the
+ message destination, but also any headers. Unrecognized headers, or
+ headers with values inconsistent with those the mail client would
+ normally send should be especially suspect. MIME headers (MIME-
+ Version, Content-*) are most likely inappropriate, as are those
+ relating to routing (From, Bcc, Apparently-To, etc.)
+
+ Note that some headers are inherently unsafe to include in a message
+ generated from a URL. For example, headers such as "From:", "Bcc:",
+ and so on, should never be interpreted from a URL. In general, the
+ fewer headers interpreted from the URL, the less likely it is that a
+ sending agent will create an unsafe message.
+
+ Examples of problems with sending unapproved mail include:
+
+ * mail that breaks laws upon delivery, such as making illegal
+ threats;
+
+ * mail that identifies the sender as someone interested in breaking
+ laws;
+
+ * mail that identifies the sender to an unwanted third party;
+
+ * mail that causes a financial charge to be incurred on the sender;
+
+ * mail that causes an action on the recipient machine that causes
+ damage that might be attributed to the sender.
+
+ Programs that interpret mailto URLs should ensure that the SMTP
+ "From" address is set and correct.
+
+8. IANA Considerations
+
+ This document changes the definition of the mailto: URI scheme; any
+ registry of URI schemes should refer to this document rather than its
+ predecessor, RFC 1738.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et. al. Standards Track [Page 6]
+
+RFC 2368 The mailto URL scheme July 1998
+
+
+9. References
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, Editors,
+ "Uniform Resource Locators (URL)", RFC 1738, December 1994.
+
+ [RFC1808] Fielding, R., "Relative Uniform Resource Locators", RFC
+ 1808, June 1995.
+
+ [RFC2047] Moore, K., "MIME Part Three: Message Header Extensions for
+ Non-ASCII Text", RFC 2047, November 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et. al. Standards Track [Page 7]
+
+RFC 2368 The mailto URL scheme July 1998
+
+
+A. Change from RFC 1738
+
+ RFC 1738 defined only a simple 'mailto' with no headers, just an
+ addr-spec (not a full mailbox.) However, required usage and
+ implementation has led to the development of an extended syntax that
+ included more header fields.
+
+B. Acknowledgments
+
+ This document was derived from RFC 1738 and RFC 1808 [RFC1808]; the
+ acknowledgments from those specifications still applies.
+
+ The following people contributed to this memo or had and discussed
+ similar ideas for mailto.
+
+ Harald Alvestrand
+ Bryan Costales
+ Steve Dorner
+ Al Gilman
+ Mark Joseph
+ Laurence Lundblade
+ Keith Moore
+ Jacob Palme
+ Michael Patton
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et. al. Standards Track [Page 8]
+
+RFC 2368 The mailto URL scheme July 1998
+
+
+C. Author Contact Information
+
+ Paul E. Hoffman
+ Internet Mail Consortium
+ 127 Segre Place
+ Santa Cruz, CA 95060 USA
+
+ EMail: phoffman@imc.org
+
+
+ Larry Masinter
+ Xerox Corporation
+ 3333 Coyote Hill Road
+ Palo Alto, CA 94304 USA
+
+ EMail: masinter@parc.xerox.com
+
+
+ Jamie Zawinski
+ Netscape Communications Corp.
+ 501 East Middlefield Road
+ Mountain View, CA 94043 USA
+
+ EMail: jwz@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et. al. Standards Track [Page 9]
+
+RFC 2368 The mailto URL scheme July 1998
+
+
+D. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman, et. al. Standards Track [Page 10]
+
projects / claws.git / commitdiff