From: IN%"stewarts@ix.netcom.com" "Bill Stewart" 29-MAY-1996 19:17:02.67
On the other hand, if the Church of Spam tries to frame remailers by posting their own Secret Documents, they can only target the terminal remailers and as far back as they can subpoena, because they'd otherwise have to admit that they posted it.
Unfortunately, you may very well be incorrect on this. I had a chat with Uni over email a couple of days ago, and he reminded me of the possibility of them doing this through an account that wasn't obviously theirs, then claiming the initial remailer operator was negligent in not filtering the mail. The way to counter this is to only accept mail that's already encrypted to another remailer (i.e., Mixmaster with outgoing mail from non-remailers only to other remailers). If the judge is going to find a remailer operator responsible for the content of material he/she can't even read, then the remailer network is dead in its present form anyway. There's also the analogous consideration for outgoing remailers; they may need to send only encrypted mail to the transient end point(s), and the end points may need to be anonymous both in input and output. If the last remailer can read the material, then the Co$ or whoever can argue that they should filter it. The end point has to be able to read it for public messages (I'm not counting encrypted posts meant for one or a few people as public messages) to go out, so the end point would be vulnerable to lawsuits, etcetera if its identity were known. We've thus got to have the initial user choosing the ephemeral end point, and sending it to that end point encrypted for that end point. Since a well-known end point (e.g., everybody knows where to send mail to) is likely to get shut down quickly (much more so for its input end than would otherwise be the case, if the input and output ends are separate), I would suggest having the ephemeral end point owners send an appropriately encrypted message to the remailer operators, or (preferably) to a subset of them (thus being able to spot any corrupted remailer who consistently blows the gaff). This message would contain the public key for an end point or set of end points, a random number associated with that public key (although a KeyID or fingerprint might do instead), plus input end addresses for each of the end points run using that public key; this would all be signed with the public key in question. (Having it on the keyservers so as to build up reputation through signatures would be good in addition, with some appropriate pseudonymous UserID to link it with). Remailer users would then get the random number plus its associated public key upon mailing a remailer with an appropriate help request. If a remailer received for output a number it didn't recognize, I would suggest remailing the information - encrypted appropriately - to another remailer. One additional advantage of this system would be that the end users wouldn't need to know about changes in input end points - their mail would simply go to whichever of the available input end points corresponding to that public key & random number that that remailer knew and happened to randomly select.
There's been some discussion of delivering outgoing mail by sending it through systems that don't add Received: headers; it may make sense for non-root-owned remailers to do this using telnet to port 25 instead of their local sendmail, to prevent local logging and prevent their sendmail from adding its own information. Some sendmails try to detect forgery, but systems that aren't even configured to do Receive: probably don't.
I had wondered about Port 25 as one possibility for this. Incidentally, I forgot to save the posting from someone who had commented about AOL sending out lots of membership kits with free net time - useful for ephemeral end points, although the anonymnity would be a problem. It might be interesting to find out what mailing lists they're getting their lists from - magazines catering to the middle+ classes is my guess. -Allen