Re: Proposal: some more standard remailer features

[hfinney@shell.portal.com]

From: rjc@gnu.ai.mit.edu (Ray)
>    Here are some proposed remailer standards some of which I have
> already implemented.
> 
> Command Formatting:
> 
>  I propose that all remailer commands start on the first non-blank line of a 
> message body and start with the string '::' followed by a command-name
> with no spaces in it. A command block should end when two blank lines are
> encountered (which are stripped from the output) or a non-blank
> line that doesn't start with '::' is encountered.

Why look for *two* blank lines to end a command block?  Why not just end a
command block when you find a line not starting with ::?

> Message Encapsulation:
> 
>  I propose a standard format for recursively storing messages in
> envelopes with standard formats.  Each envelope should begin with the
> command "::envelope" followed by the envelope method, followed by the
> body. The end of the "envelope" is specified with ::end METHODNAME

This is reminiscent of MIME.  Have you looked at that?  They already deal
with encapsulation as well as message splitting, I think.  You could copy
their message formats without committing to full MIME support.  Plus it
might be possible to add encryption and remailing support to MIME mail user
agents by using the hooks they already provide.

>   I propose the header pasting token, "::@" which gets applied
> only after the message is delivered to someone (not chained).
> For example
> ::@Subject this is the subject line
> ::@From    this is the from line
> ::@x-foo   this is the x-foo: header

The only thing that seems wrong about this is that the remailer apparently
has to know whether it is sending to a person or another remailer.  I think
you should follow instructions about pasting these header fields by what
the user has requested rather than deciding for him.  Maybe I don't under-
stand exactly how Ray is proposing that these commands be used.

>   Depending on how the remailer is set up, incoming subject headers
> may or may not be preserved.

I would recommend that they not be preserved, but I suppose that is up to
the operator.

This may sound crazy, but I am concerned about adding these features which
make the system too easy to use.  It seems that at the limit a person can
just put "::To: friend@college.edu#remailer1#remailer2#*#*#remailer3" at
the top of his message and his mail goes zipping down this extremely com-
plicated path.  But the problem is that this is really deceptive in
terms of how secure it is.  All this ease of use is at the expense of having
to put a lot more trust into one or a few remailer operators.

It's not clear that it's better to provide the temptation of easy-to-use but
falsely secure remailers.  At least with Julf you know you're trusting him.
With addresses like the above users may not realize how many eggs they're
putting into that first remailer's basket.

> EXAMPLE MESSAGE:
> 
> ::envelope PGP
> [PRETEND EVERYTHING FROM HERE DOWN IS ENCRYPTED FOR THE REMAILER]
> ::to ann's_remailer#darkmodem
> ::@Subject Hello World
> 
> <Message text>
> ::end PGP
> 
> when sending this out, the remailer might encrypt the message
> for ann's remailer and split it into two pieces
>  [...]
> Now when ann's remailer receives a two parted message, it queues
> each piece until it gets the full message (timing out after a few
> days) After all pieces are received, it removes the envelopes,
> pieces the message together, and sends the message off to darkmodem
> (which may be a virtual address for lightmodem#bob's_remailer)

This kind of splitting would be more useful if it were carried through
to the end user.  Otherwise the reassembled message is conveniently
provided for inspection by the spooks as it goes to him.  Again, I think
MIME may provide for reassembly at the end user.

>  I also propose ::route which would specify preferences preferred for
> remailers when searching for other remailers to chain your
> message to. e.g.

Would this be used with the "*" remailer-chooses-remailer feature?  If the
user specifies the path then presumably there is no provision for remailers
to make choices like these.

Despite my concerns, I think Ray has so many good ideas here that it will
be great to see his software operating.  The "market" for remailers is the
users who want both privacy and ease of use.  Ray's enthusiasm and energy
in putting all these ideas into code will go a long way towards finding out
what kinds of trade-offs the market wants.

Hal