Internet-Draft Paul Hoffman draft-hoffman-mailto-url Larry Masinter January 7, 1997 expires June 7, 1997 The mailto URL scheme Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 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 to be specified as well as the mail address, the mailto URL scheme is extended to allow setting mail header fields. 2. Syntax of a MAILTO URL Following the syntax conventions of [RFC URL SYNTAX], a "mailto" URL has the form: mailtoURL = "mailto:" [ addr ] [ headers ] headers = "?" 1*( hname "=" hvalue ) addr = *urlc hname = *urlc hvalue = *urlc where addr is (the encoding of) an addr-spec as specified in RFC 822 [1], and hname and hvalue are encodings of an RFC 822 header name and value, respecively. Note that all URL reserved characters must be encoded; in particular, the percent sign ("%") is commonly used within RFC 822 addresses and must be encoded. The special hname "body" indicates that the associated hvalue is the body of the message. Within mailto URLs, the characters "?", "=", "&" are reserved. 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. A "mailto" URL has unusual semantics because the operation of "GET"ing such a URL does not usually result in the immediate retrieval of an information object. Rather, the GET operation merely opens an interactive user session for mailing to the designated address with the various header fields set as default; the POST operation results in the sending of electronic mail to the designated address with the POSTed body replacing the body of the message. 4. Unsafe headers The user agent interpreting a mailto URL may 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. Headers that clients might consider dangerous include: Apparently-To Bcc Content-Encoding Content-Length Content-Transfer-Encoding Content-Type Date Distribution Fcc Followup-To From Lines MIME-Version Message-ID Newsgroups Organization Reply-To Sender X-UIDL XRef 5. Examples A URL for an ordinary individual mailing address: mailto:masinter@parc.xerox.com mailto:ietf-url@imc.org A URL for a mail response system that requires the name of the file in the subject: A mail response system that requires a "send" request in the body: A similar URL could have two lines with different "send" requests: A request to subscribe to a mailing list: 6. Encoding RFC-URL-SYNTAX 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. 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 that the mail messages appear in a form that the recipient will understand. These strings should be decoded before showing the user the mesage. 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. 7. Security The mailto scheme is intended 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), 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. 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 8. Acknowledgements This document was derived from RFC 1738 [2] and RFC 1808 [3]; the acknowledgements from those specifications still applies. 9. References [1] RFC 822 [2] Berners-Lee, T., Masinter, L., and M. McCahill, Editors, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994. [3] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC Irvine, June 1995. [RFC-URL-SYNTAX] Berners-Lee, T., Fielding, R., Masinter L., "Uniform Resource Locators (URL)", Work in Progress , MIT/LCS, U.C. Irvine, Xerox Corporation, October 1996. Appendix A. Change from RFC 1738 RFC 1738 defined only a simple 'mailto' with no headers, just an address. However, required usage and implementation has led to the development of an extended syntax that included more header fields. Author contact information: Paul E. Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA Tel: 408-426-9827 phoffman@imc.org Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94304 USA masinter@parc.xerox.com