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