Second round for new URL scheme (mailserver)

Thank you for all the comments on pre-draft 1. Below is pre-draft 2, which
I think answers all the issues brought up. In doing so, it also opens a few
more that should be discussed before I commit it to full IETF draft-hood.

Security: I added a discussion about the need for client software to show
the user the full message before sending it.

Name: Based on Dirk's OK, I changed the name of the scheme to "mailserver",
which is already quasi-reserved in RFC1738. After reading the pros and
cons, I still chose not to try to extend mailto because I'm pretty sure
many current versions of Web clients will break if I did. This is not to
say that we can't make changes to any existing schemes. However, the
changes made here are new fields and the URLs need to be parsed completely
differently. To me, the makes "mailto" useful for people and "mailserver"
useful for, well, mail servers.

Scalability: Dirk pointed out that whatever we do now should be made
scalable so that it doesn't have to be revised later (and to prevent the
need for a third "mailxxx" scheme!). Thus, I added the optional additional
headers at the end of the URL, and pointed out the security problems of
them.

Encoding: I added notes about encoding.

If there aren't any big problems shown this week, I'll turn this into a
real IETF draft and let the folks at the IANA know that "mailserver" has a
draft definition. I'll also contact the big Web client writers so that it
can be included.

--Paul Hoffman

===============

Status of this memo

<insert generic Internet Draft preamble here>

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:<rfc822-addr-spec>/<subject>/<body>/[<other-headers>]

Client software would prepare a mail message with the <subject> text as the
subject 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.

Examples

A URL for a mail response system that requires the name of the file in the
subject might be:

<mailserver:infobot@kwf.com/current-issue//>

A mail response system that requires a "send" request in the body might
have a URL that looks like:

<mailserver:infobot@kwf.com//send%20current-issue/>

The "mailserver" scheme would also help people get another type of Internet
resource, namely mailing lists. For example:

<mailserver:majordomo@kwf.com//subscribe%20bamboo-l>

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 two examples above that use
"%20" for space in the message body.

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.

Additional headers

A mailserver URL can include additional headers for the client software to
add to the message. Each header is in the form:

<header-name>:<text>/

Thus, a URL with a "bcc:" header might look like:

<mailserver:infobot@kwf.com/current-issue//bcc:jean@kwf.com/>

See the "Security" section below for important considerations for using
additional headers.

Additional BNF for RFC1738

mailserverurl    = "mailserver:" encoded822addr "/" subject_text "/"
                   body_text "/" *[extra_header "/"]
subject_text     = *[uchar]
body_text        = *[uchar]
extra_header     = encoded822header ":" extra_text
encoded822header = 1*xchar  ; further defined in RFC822
extra_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) 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 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 has additional headers, these headers can cause
security problems, such as identifying the sender to a malicious third
party. Further, the additional headers can cause undefined actions in some
mail programs that may compromise security. Security-conscious mail clients
should scrutinize the additional headers and their contents before
including them in mail messages; some clients might even choose to ignore
some or all of the additional headers 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

Received on Monday, 9 January 1995 19:14:33 UTC