Re: Proposal: some more standard remailer features
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
Ray <rjc@gnu.ai.mit.edu> said:
Two problems instantly jumped out at me when reading the MIME documents:
1) more than 2-level encodings are not supported (no recursion)
Why is this a problem? A MIME "Content-Transfer-Encoding" context is a reversible transformation that is made to permit binary or other non-email-friendly data to be carried in an email-friendly form. Once you have performed the encoding once, the result is email-friendly, so there is usually no need to emcode it again. Note that MIME places no restrictions on the nesting of multipart messages; it merely requires that the content-transfer-encoding be applied only at the innermost levels of the nesting.
2) no application/viewpgp or transfer-encoding: pgp type
I have been trying, on and off, for about two years to persuade the PGP folk to design a suitable MIME interface for PGP, modelled as closely as reasonable on the ongoing PEM-MIME work. Nobody ever seems to be interested in that, but several folk have come up with their own ad-hoc methods. You could come up with your own ad-hoc method, or adopt one of the others, or design something that is compatible with the PEM-MIME stuff. If anybody is interested in designing a PGP-MIME encapsulation that is compatible (or nearly compatible) with PEM-MIME, I volunteer to help. --apb (Alan Barrett)
On Apr 6, 11:10am, Alan Barrett wrote:
If anybody is interested in designing a PGP-MIME encapsulation that is compatible (or nearly compatible) with PEM-MIME, I volunteer to help.
I can't volunteer help at this time, but am willing to *pay* $100 for a working copy I can use with MediaMail, if it's delivered by 6 May 1994. I will pay $50 between 7-21 May, and $25 thereafter. Russell
-- End of excerpt from Alan Barrett
-- Russell Earl Whitaker whitaker@sgi.com Silicon Graphics Inc. Technical Assistance Center, Mountain View CA ================================================================ #include <std_disclaimer.h>
Actually, there is work underway to to generate an inter-operation between MIME and PGP, similar to the interoperation between MIME and PEM. It will *not* have detached signatures (i.e., a signature in one MIME part which is signing another part). The idea is to have two PGP types, one that is defines a PGP-encoded text object, and one that defines a PGP-encoded MIME object. When using a text-object, it will just use PGP. When its a MIME object, the output from PGP will be run through a MIME program again (like metamail). Details are still being drawn. -derek
participants (4)
-
Alan Barrett -
Derek Atkins -
rjc@gnu.ai.mit.edu -
whitaker@dpair.csd.sgi.com