W3C home > Mailing lists > Public > uri@w3.org > January 1995

Re: mailserver URL

From: Dirk Herr-Hoyman <hoymand@gate.net>
Date: Wed, 25 Jan 1995 19:52:25 -0500
Message-Id: <ab4cf49911021004d908@[]>
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>, uri@bunyip.com
At 10:42 PM 1/25/95, Roy T. Fielding wrote:

>> 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.
Although I don't see this as posing a threat, neither do a see any mail
servers out that that depend on non-Subect header fields.  Since I
originally started the specification for the mailserver URL with the goal
of providing a means to existing mail servers and extensibility second, I
can live to the removal of arbitrary fields as a way of reaching consensus.

>If we want to have a mailserver URL, the format should be
>    mailserver:address[/<subject>[/<body>]]

Hmmm.  This doesn't seem quite right to me.  You are requiring that a
Subject: field be included if there is a body.  Many mail servers ignore
the Subject: altogether.  I was thinking more along the lines of using a
//, i.e. a blank line, to signify the start of the body.


would work, for example.
>In addition, both subject and body should be restricted to disallow
>the hex codes for CR and LF (%0D and %0A).

Right, that we are letting the / serve as the end of line.  Does make for a
special case in the URL parsing, which I was hoping we could avoid, but
it's not a terribly difficult one.

>  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.
So, do we know what these shell escapes are?  I'm assuming you are refering
to something that causes a problem on the server side.  If so, I'm not sure
how we can come up with a list of prohibited characters.  Or perhaps I'm
just not comprehending the risk here, in which case could you elaborate?

Dirk Herr-Hoyman <hoymand@gate.net> |          I tried to contain myself
CyberBeach Publishing               |                                but
   * Internet publishing services   |                          I got out
Lake Worth, Florida, USA            |
Web: http://www.gate.net/cyberbeach/
Phone:     +1.407.540.8309
Received on Wednesday, 25 January 1995 19:53:35 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:29 UTC