Remailer abuse

-----BEGIN PGP SIGNED MESSAGE-----

From: Brad Huntting <huntting@glarp.com>

> Custom headers in RFC822 messages must begin with "X-".  Making up
> new headers that dont begin with "X-" is unnessary and violates
> the standard.

What RFC 822 actually says is this:
  
    4.7.4.  EXTENSION-FIELD
    
    	A limited number of common fields have been defined in
    this document.  As network mail requirements dictate, additional
    fields may be standardized.  To provide user-defined fields with
    a measure of safety, in name selection, such extension-fields will
    never have names that begin with the string "X-".
    
    	Names of Extension-fields are registered with the Network
    Information Center, SRI International, Menlo Park, California.
    
    4.7.5.  USER-DEFINED-FIELD
    
    	Individual users of network mail are free to define and
    use additional header fields.  Such fields must have names which
    are not already used in the current specification or in any
    definitions of extension-fields, and the overall syntax of these
    user-defined-fields must conform to this specification's rules for
    delimiting and folding fields.  Due to the extension-field
    publishing process, the name of a user-defined-field may be pre-empted.
    
    Note: The prefatory string "X-" will never be used in the names of
    Extension-fields.  This provides user-defined fields with a protected
    set of names.

I must say, this is a refreshingly non-facist RFC.  There are few of
the prohibitions which we are accustomed to seeing in these "laws of
the net".  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.  That's why people use X-.

Hal
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBK23k7agTA69YIUw3AQFUTAP/UScvi9FOj4o31sjsqmz/xIJ90KB7WnK5
8m4yKX/p46IbH9+FhSvgBfURokh7+dSk91+GR6NPM/4rXEm+5aMbee6uuMsJaTF/
qPmmen1JnvtabTZi9s0HeQ2frqK7kolr0GIair7U8CiPhX1QVNx0IwzYB6g9YQmP
Zv84fGUzGEw=
=U54Y
-----END PGP SIGNATURE-----

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