Re: mailserver URL

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

Received on Saturday, 4 February 1995 00:56:12 UTC