# Re: mailserver URL

Roy T. Fielding (fielding@avron.ICS.UCI.EDU)
Fri, 03 Feb 1995 21:53:43 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Roy T. Fielding: "Re: A content-id URL scheme"
- Previous message: Ed Levinson: "A content-id URL scheme"
- In reply to: Stephen R. van den Berg: "Re: mailserver URL"
- Next in thread: Gary Adams - Sun Microsystems Labs BOS: "Re: mailserver URL"

    To: "Stephen R. van den Berg" <berg@pool.informatik.rwth-aachen.de>

    Subject: Re: mailserver URL

    In-Reply-To: Your message of "Tue, 31 Jan 1995 13:48:55 +0100."

                 <9501311248.AA14007@tabaqui>

    Date: Fri, 03 Feb 1995 21:53:43 -0800

    From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>

    Message-Id:  <9502032153.aa27830@paris.ics.uci.edu>

> In principle I'm charmed by the scalability of the approach to allow
> arbitrary header fields to be specified. But, if people consider this
> to be too much of a security hazard, why not simply state in the RFC that
> implementors should initially ignore any header fields except Subject, and
> that on explicit configuration, some specified headers fields are to be
> accepted.

For three reasons:

1) Adding arbitrary headers does not provide any additional scalability,
nor does it provide any additional extensibility (what you meant).

Mail servers need to be able to accept requests from mail agents.
Many mail agents do not allow users to send arbitrary headers. Some
mail gateways change the content and order of mail header fields.
Some mail gateways drop all unknown header fields. Therefore, mail
servers must provide a way for these fields to be given in the body
of a message instead of the header.

MIME explicitly deprecates the use of Subject for mail-server commands,
and only allows it because some existing mail servers do require a subject.
MIME does not allow any other header fields to be used in a mail-server
access.

Allowing the mailserver URL to do something that other mail agents
cannot do (or, for security reasons, are explicitly prevented from
doing) is unnecessary. Providing a feature for mail server access
that is not even allowed by MIME is a total waste of time.

2) It requires the user agent to perform additional work and to support
an interface that displays arbitrary header fields instead of just subject.

Consider what it would take to implement an interface that allows
the user to see, recognize, and *understand* any arbitrary header field
that may be configured for use by an application. Note that the
application may have been configured by someone other than the user.
Now, compare that to one where you know that the only fields are the
address, subject, and body content.

3) It adds the case-insensitive string "subject:" to any mailserver URL
that includes a subject.

> This way you can have the best of both worlds. I.e. the RFC doesn't forbid
> the use of extra fields, it just recommends that they are ignored by default.
> It would allow an implementation to allow some header field to be included
> if it became popular some time in the future.

If the URL is intended to fulfill the requirements of access to a
mailserver, this additional complexity is completely unnecessary.

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

- Next message: Roy T. Fielding: "Re: A content-id URL scheme"
- Previous message: Ed Levinson: "A content-id URL scheme"
- In reply to: Stephen R. van den Berg: "Re: mailserver URL"
- Next in thread: Gary Adams - Sun Microsystems Labs BOS: "Re: mailserver URL"