From: Hal <hfinney@shell.portal.com>
Date: Sat, 2 Apr 94 17:34:50 PST
To: cypherpunks@toad.com
Subject: REMAIL: standardized remailer syntax
Message-ID: <199404030148.RAA10520@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


From: nowhere@bsu-cs.bsu.edu (Chael Hall)
> Sameer writes:
> 
> >	Here's my suggestion..
> >
> >	Header pasting:
> >	The '::' header pasting syntax should be available-- i.e. when
> >a message comes into a remailer with a body starting with '::' the
> >lines following until a blank line are pasted into the header.
> >
> >	The '##' header pasting syntax-- when a remailer is sending
> >out a message, if the body begins with a '##' line then the lines
> >following that are pasted into the header of the outgoing message.

I like Sameer's goal of standardized syntax, but I have to admit that I
find the :: and ## bit confusing, and hard to explain.

The way Eric Hughes' original remailer worked was that the "remailer
commands" were in the message header, up with Subject and In-Reply-To and
such.  However, many mailers won't let people put custom material there, so
the "::" pasting token was invented to take the following lines and put
them into the header before the remailer processed them.  The effect was
that you could put remailer commands after "::" and they would work.

But there were also some situations in which the user might want to
control message headers as they *leave* the remailer.  For example,
they might want to put a Reply-To to some anon pool so that they could
receive reply messages.  So Eric created the "##" pasting token for
those.  The remailers based on his scripts first look for "::" and add
in any headers following it; then they process the message, looking for
command lines in the header; then as they remail it they look for "##"
and stick any following lines in the outgoing message header.

This all makes sense but it makes for a complicated system.  I think people
would find it easier to understand an approach in which they put remailer
commands at the top of their message, marked in some way to separate them
from the rest of the message.  "::" on a line by itself could indicate the
beginning of a block of remailer commands, terminated by a blank line.
Or, as an alternate syntax, each remailer command line could start with
"::" followed by the text of the command.  Both approaches have been used
by different software on the net and they could be considered two different
ways of expressing the same thing.

This would get away from the add-to-header/process-header/add-to-header
approach of the current Perl remailer scripts and use a simple one-step
"process remailer commands" approach which I think would be simpler.  You
could still have all the functionality of the current approach (perhaps a
paste-outgoing-header command could be used for the "##" functionality) in
a package which is conceptually simpler (to me, at least).

Another advantage of this approach is that you could make use of the order
of the commands in the remailer block so that you could have finer control
over what you are asking the remailer to do.

> >	Header commands:
> >	"Anon-To","Request-Remailing-To": strips headers and sends the 
> >message to the specified recipient.
 
I would suggest abandoning one of "Anon-To" or "Request-Remailing-To",
as they are redundant.  I know above I suggested two redundant ways of
specifying remailer commands; maybe that should be reduced to one, as well.

> 	1.  The bsu remailers no longer paste ANYTHING from a "::" header
> 	    into the header of the outbound message.

Many of the remailers pass Subject lines.  I don't think they should.
Chael's approach makes sense to me.  The best thing is to have a way to
set the subject as the message leaves the last remailer in the chain.  (My
"chain" program does this automatically.)

> 	3.  They also support multiple recipients.  You can place as many
> 	    "Request-Remailing-To:" lines in the headers as you wish and
> 	    it will individually address and send each one.

I sent mail a few minutes ago (before seeing Chael's message) suggesting
the danger of this in making it easy to create huge numbers of messages.

> 	4.  Full debug logging has been turned on until I can verify that
> 	    both remailers are acting as they should.  This form of logging
> 	    includes a mirror of the message as it is received and a
> 	    one-line message listing each recipient.

We have had a lot of talk about logging.  My feeling is that one should get
security in using the remailer network by going through a number of machines
in widely different regions.  It should not, as was suggested here some time
ago, be a matter of trusting any given remailer operator.  Privacy is not a
gift being provided by remailer operators to their users.  It is still some-
thing that the users must provide for themselves.  The remailers are just a
tool to help achieve that.

Thanks to Chael for re-kindling this discussion.

Hal