IETF URI Working Group Internet-Draft draft-ietf-uri-url-mailserver-00.txt Expires July 23, 1995 Mailserver URL Specification 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 A new URL scheme, "mailserver", is defined. It allows mail client software to create RFC822 mail messages from a URL. Description In the URL specification, RFC1738, the "mailto" scheme is defined and is described as: Unlike many URLs, the mailto scheme does not represent a data object to be accessed directly; there is no sense in which it designates an object. However, there are many resources on the Internet that can only be accessed by mail that cannot be described by the mailto scheme. To access such an object, the mail message must have a specified subject and/or content. For instance, many mail response servers will return a file if you send a mail message with the proper request. The "mailserver" URL has the form: mailserver:/*[

/]/ Client software would prepare a mail message with the given headers and the text as the body of the message. Thus, the "mailto" scheme will be used to give the mailing address of a person or of a mailserver that requires no subject or message body; the "mailserver" scheme is used to give a template that will cause the specified resource to be returned. Headers are given in RFC822 format, and it is likely (and probably preferable) that only a "Subject:" header be included. Headers are given without spaces after them, such as "Subject:current-issue". The body text may span more than one line. Any "/" character in the body should be interpreted by the mail client as a CRLF sequence when translating a URL to a mail message. Examples A URL for a mail response system that requires the name of the file in the subject might be: A mail response system that requires a "send" request in the body might have a URL that looks like: A similar URL could have two lines with different "send" requests: The "mailserver" scheme would also help people get another type of Internet resource, namely mailing lists. For example: Encoding RFC1738 requires that many characters in URLs be encoded. This affects the mailserver scheme for some common characters that might appear in subjects or message contents. Two such characters are space (" ", ASCII hex 20) and forward slash ("/", ASCII hex 2F). Note the examples above that use "%20" for space in the message body. Note further that an unencoded forward slash in the body area (after the "//") is to be translated by the mail client to CRLF. People creating mailserver 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. Specifying Headers A mailserver URL can include headers for the client software to add to the message. Each header is in the form: :/ Thus, a URL with a "Subject:" header, a "X-magic" header, and a body might look like: See the "Security" section below for important considerations for using headers. Additional BNF for RFC1738 mailserverurl = "mailserver:" encoded822addr "/" *[header "/"] "/" body body = [body_line] *["/" body_line] body_line = *[uchar] header = encoded822header ":" header_text encoded822header = 1*xchar ; further defined in RFC822 header_text = *[uchar] Security The mailserver 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 mailserver 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 mailserver URL without first showing the user the full message that will be sent (including all headers, including those specified in the URL), fully decoded, and asking the user for approval to send the 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 goes to an unwanted party, such as through a "cc:" or "bcc:" header - 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 If a mailserver URL specifies headers, these headers can cause security problems, such as identifying the sender to a malicious third party. Further, headers other than "Subject:" can cause undefined actions in some mail programs that may compromise security. Security-conscious mail clients should scrutinize the headers and their contents before including them in mail messages; some clients might even choose to ignore some or all of the headers other than "Subject:" in a URL. Author contact information: Paul E. Hoffman Proper Publishing 127 Segre Place Santa Cruz, CA 95060 USA Tel: 408-426-6222 phoffman@proper.com