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