From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 2 Feb 93 19:20:21 PST
To: cypherpunks@toad.com
Subject: mail policy
In-Reply-To: <9302020633.AA16727@soda.berkeley.edu>
Message-ID: <9302030317.AA06908@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Brad:
>> Custom headers in RFC822 messages must begin with "X-".  

As Hal points out, this is not true.

Hal:
>In particular, users can use any header fields they want,
>as long as they aren't already used; they only risk being made obsolete
>if their chosen field names become used.  

Let me make this point explicit, in case I haven't done so recently.

	Anonymity and pseudonymity should be standard
	features of electronic mail systems.

When I first picked the names for the header fields, I read RFC-822
carefully, and specifically chose *not* to use X- extension headers.
I fully intend to write an RFC, an extension to RFC-822, which
describes the syntax and semantics of anonymous/pseudonymous mail
messages.  There will likely be another describing the operation of a
"standard remailer."

(A note about MIME: I'm talking about the transport system here,
underneath the layers that MIME puts on.  At least that's the idea.)

The current policies favoring named mail originate in the conflation
of two notions of security.  The first, delivery security, is that the
mail be delivered correctly, i.e., delivered at all, to the correct
person, in a timely fashion, without alteration of the contents.  The
second, liability security, is that the provider of mail not be held
liable for content.  The provider removes liability by transferring it
to the sender of the message, who must therefore remain named.

One goal of remailer work is to cleave these two notions apart.  A
provider of email services should be responsible for accurate and
timely delivery, but should have no concern for or hand in content.
The service that the provider is offering is just that, computer
services.  It is not monitoring, not oversight, and not censorship.
Just as the phone company provides a communication channel on which I
may put whatever content I desire, so should any e-mail system offer
a communication channel and only a communication channel.

The origin, I believe, of this confusion is that e-mail systems were
by and large developed for internal uses and not for the open market.
That internal use, broadly conceived, might be for the military, for
academic research, or for intra-corporate memos.  In other words these
systems were provided (mostly) free of incremental charge to the
users.

In this environment, where service is being provided by context, it
was the legitimate concern that the provider might be held liable,
since the provider, in some strong sense, had caused the service to
exist in the first place.  When the social structures and situations
or e-mail communications were all so similar, this system worked out
fine.

Today, however, people seek out e-mail services for their direct
utility.  These people often have no prior relation with their service
provider; indeed, they wish not to be tied to a particular provider as
a guard lest the quality of the service suffer.  These people pay for
service themselves, typically.

And hence the separation between liability security and delivery
security is complete.  I want to buy common carriers of e-mail.  I
want bit pipes.  (Or, perhaps, in the e-mail world, bit bucket
brigades.)

But the standards of yesteryear are still with us.  The structure of
named mail persists.  We are changing that.  We do not wish to remain
skulking in the corners of respectability.  We want to be standard.
We want the standards, too, to be ours and to reflect our concerns.

Let us act with the care and deliberation that behoove all those who
wish to create standards to which others comply.

Onward.

Eric