From: rjc@gnu.ai.mit.edu (Ray)
Date: Wed, 6 Apr 94 01:16:51 PDT
To: cypherpunks@toad.com
Subject: Re: Proposal: some more standard remailer features
Message-ID: <9404060815.AA28162@geech.gnu.ai.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


Hal writes:
> From: rjc@gnu.ai.mit.edu (Ray)
> > 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 ::?

   Experience from the Extropians list. A large number of people
made the mistake of inserting blank lines between commands and
some people's mailers did it automatically (one of the more
stupider one's actually removed a leading colon from the line
changing ::exclude to :exclude) I got a lot of complaints, so I removed
the restriction of single blank lines being able to terminate. In fact,
the regular expression which parses lines looks like this:

/^\s*::\s*(.*)$/

  So that spaces are allowed before and after the '::'

  On the extropians list, an arbitrary amount of whitespace is allowed
because ':::' is used to separate command blocks from the body of
messages.

> > 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 thought of MIME, but I didn't know it was so popular (I last
looked at it over a year ago). I just looked at the comp.mail.mime
FAQ and the RFCs and I see that MIME is gaining momentum. Two problems
instantly jumped out at me when reading the MIME documents:

1) more than 2-level encodings are not supported (no recursion)
2) no application/viewpgp  or transfer-encoding: pgp type

   MIME actually takes care of the multipart issue nicely. I'm going to
do some more research and I may end up scraping ::envelope if MIME's
encapsulation is powerful enough for inter-remailer I/O. (the one
pain in the butt is that now I will have to process the headers
instead of throwing them away) Perhaps the PEM/MIME documents will be
of help.

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

   Correct. You don't want headers to be visible during the chaining,
and the remailers throw away incoming headers. Therefore, I felt
that ::@ shouldn't be applied until the message is posted or
sent to a real e-mail address. Any suggestions on a better
method?

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

   You could concentrate your trust on the first remailer in the chain.
Once it goes through that remailer, it is now encrypted for the
recipient and the source of the message is destroyed. Keep in mind,
the other remailers in the chain can not snoop on the message because
it is encrypted for the recipient automatically (if a key is present).
The other remailers can do traffic analysis if the user doesn't
use any wildcards ("*"), but this can be limited using recursion. e.g.

::envelope PGP 
::to remailer1
::envelope PGP [for remailer 1]
::to remailer2
::envelope PGP [for remailer 2]
::to remailer3
::envelope PGP [for friend]
::to friend@college.edu

   I agree most of the power should be in the client (hopefully,
my approach allows both a powerful client or simplemail use), but
there also needs to be a "lowering of transaction costs" as Eric
suggested. Many people don't have unix accounts and with the advent
of Compuserve/Delphi/Genie/AOL internet gateways, some sort of
server approach is required.

   Part of the reason for including a socket-server in the remailer
is to allow clients to hook into the network and get data fast.

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

   If I understand correctly from my fast reading, it does: the
multipart/partial content-type. (the comp.mail.mime faq is an example)
The hurdle is getting a MIME type registered which can recognize
pgp encrypted and/or signed messages.

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

   Correct. It would be used with the "*" feature and also the
auto-chaining. (if a user just says ::to friend@college.edu, the
remailer may choose to chain this through several other remailers
automatically)

Thanks,

-Ray