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).


   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

   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

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:


5. Examples

   A URL for an ordinary individual mailing address:


   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
       <draft-uri-url-syntax-00>, MIT/LCS, U.C. Irvine, Xerox 
       Corporation, October 1996.


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

   Larry Masinter
   Xerox Corporation
   3333 Coyote Hill Road
   Palo Alto, CA 94304 USA

Received on Wednesday, 8 January 1997 02:19:33 UTC