mailserver scheme, third round

Thank you for all the comments on pre-drafts 1 and 2. I think we're almost
ready here. I'm putting this out as another pre-draft so we can make sure
there's a fair amount of agreement before writing it up as a full draft.

Only a few changes:

Headers: I moved all the headers to before the body text, so the subject is
no longer special.

Multi-line bodies: I specify that unencoded "/"s in the body are to be
translated as CRLFs. This makes the URLs a bit easier to read, although
space characters will still look like one-fifth (%20).

Security: After Roy's comments, I strengthened the warnings about
non-Subject headers. I agree with him that there is no need for them now,
but I also see no need to exclude them at the specification level since
this makes it unscalable.

If there aren't any big problems shown this week, I'll turn this into a
real draft and let the folks at the IANA know that "mailserver" has a


Status of This Memo

<insert generic Internet Draft preamble here>


A new URL scheme, "mailserver", is defined. It allows mail client software
to create RFC822 mail messages from a URL.


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:


Client software would prepare a mail message with the given headers and the
<body> 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.


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:



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 two 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]


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

Received on Sunday, 15 January 1995 01:29:46 UTC