1996-05-31 - Re: An alternative to remailer shutdowns

Header Data

From: “E. ALLEN SMITH” <EALLENSMITH@ocelot.Rutgers.EDU>
To: stewarts@ix.netcom.com
Message Hash: de8719987582dd65a3cf539fcee7898265c94251f6f08734ee05e510ee7e2559
Message ID: <01I5BYGFWN5S8Y52RR@mbcl.rutgers.edu>
Reply To: N/A
UTC Datetime: 1996-05-31 08:58:24 UTC
Raw Date: Fri, 31 May 1996 16:58:24 +0800

Raw message

From: "E. ALLEN SMITH" <EALLENSMITH@ocelot.Rutgers.EDU>
Date: Fri, 31 May 1996 16:58:24 +0800
To: stewarts@ix.netcom.com
Subject: Re: An alternative to remailer shutdowns
Message-ID: <01I5BYGFWN5S8Y52RR@mbcl.rutgers.edu>
MIME-Version: 1.0
Content-Type: text/plain


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





Thread