mailserver URL

> The "mailserver" URL has the form:
> 
>      mailserver:<rfc822-addr-spec>/*[<header>/]/<body>
> 
> 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".

I'd like to reiterate my opposition to this format.  If the purpose of
this URL is to allow the retrieval of or subscription to resources of
a Mail server, there is no reason to allow any header fields to be
specified other than Subject.  It is very unlikely for a mail server to
require special header fields as part of a request -- to do so would
remove access from all those users without knowledge and/or access to
rfc822 headers.  In all cases where such header fields are used, the
mail server can allow them to be given at the beginning of the message
body, where they are relatively safe from transport effects.

Arbitrary header fields introduce an unacceptable security hazard.  There
is simply no way for a program to know, in advance, what header fields on
any given mail system could cause unintentional or undesired side-effects.
Having the user verify them does not significantly reduce the hazard --
most users of these systems do not know what headers are, let alone
what they mean.  Having the system ignore any unknown fields is equivalent
to not allowing them in the first place.

If we want to have a mailserver URL, the format should be

    mailserver:address[/<subject>[/<body>]]

i.e.

    mailserverURL = "mailserver" ":" rfc822-addr-spec
                    [ "/" subject [ "/" body ] ]

In addition, both subject and body should be restricted to disallow
the hex codes for CR and LF (%0D and %0A).  Also, the security section
should contain a warning to user agent developers to be aware of the
security limitations of an external mail agent if one is used to handle
the message. In particular, some mail agents allow special characters
to act as shell-escapes (to allow execution of commands within the mail
environment) and these need to be avoided by the user agent before 
attempting to use the URL.

If people feel this is too restrictive, than I suggest that the name be
changed to "mailmesg".  That is what has been defined by the current draft.

I would allow a restricted mailserver URL to be implemented on our
systems -- its usefulness would justify the risk.  However, I would
never allow a "mailmesg" (or its equivalent) to be implemented -- the risk
is simply too great to allow arbitrary messaging within a URL.


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Wednesday, 25 January 1995 18:06:59 UTC