From: Hal <74076.1041@CompuServe.COM>
Date: Sat, 27 Mar 93 15:28:58 PST
To: CYPHERPUNKS <CYPHERPUNKS@toad.com>
Subject: REMAIL: Anon. remailers
Message-ID: <930327232156_74076.1041_FHD20-1@CompuServe.COM>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

Kenneth G. Hagler, "Lord Krieg" <CVADSAAV@CSUPomona.Edu>, writes:

> Joe Thomas has suggested that a group of penet-style anonymous servers 
> be set up to act as "front ends" for the Cypherpunk remailers. This seems 
> like a good idea (provided that the technical problems can be overcome), 
> but I'd like to propose an addition.

I don't see the advantage of having behind-the-scenes remailers.  The
addresses of the front-end remailer(s) will have to be advertised,
and that is where people will think of the service as originating.  That
is where their attacks will be focussed.  It won't matter if there
are other systems involved with the remailing.

If one front-end gets shut down then yes, it would be nice to have
another.  Again, I don't see how this is made much easier by the
existance of multiple back-end systems.  Penet has not been replaced
yet, and I think the reason is because nobody wants to take the heat
for running such a system.  What difference does it make whether you
are running front-end software or an entire remailer?  Either way you
have to be a system manager in order to install new mail aliases
("an12345", etc.).  There just aren't that many system managers out
there willing to take on the traffic load and the political heat for
a service which they may not even believe in that strongly.

> Now, as I understood the suggestion from Joe Thomas, the Cypherpunk 
> remailers behind the front ends would only be "visible" to the people 
> involved in running the service. This would certainly make the remailers 
> more secure, since the net.fascists would not know who to terrorize to 
> can the remailers.

Again, saying that it is the back ends which are the remailers is
misleading.  As far as the net at large will be concerned, it is the
front end which is the remailer.  That is where you send your mail if
you want it to be remailed.  That is where the heat will be.  And
shutting down all the front ends will shut down the remailing service.
The existance of back ends does not affect the strategy used by our
opponents, nor does it give us any additional defense that I can see.

> Although I certainly may be misunderstanding something, I don't really 
> see why the users of the service would ever need to see a message about 
> "if mail to here bounces, try there." Shouldn't the loss of a remailer be 
> dealt with entirely "behind the scenes," by the service administrators?

How could this be done?  If I still try to send mail to an1234@anon.penet.fi,
it will not be remailed.  If Julf does start enabling such messages to
be remailed, by forwarding or by any other way, he will presumably face
the same consequences which convinced him to stop.

On the other hand, if all messages from a remailer say "reply to address
A; if that doesn't work try B, and then C" then I can guarantee that when
net powers try to shut down the remailers they will go after A, B, and C.
Exposing their names like that will just give opponents of anonymity more
time to marshall their forces against these alternative remailer sites.

I think the only reasonable approach is to make the remailer code widely
available, and to try to convince people to run it who are in a position
not to be exposed to pressure.  From earlier postings here, it sounds
like someone who is paying his own money for a UUNET connection, which
someone said costs about $50 per month (what does that $50 include?),
would be a good choice.  It sounds like UUNET is not going to cut off
a paying customer just because others complain about his use of the net,
particularly if it is true that UUNET is a immune to legal threats about
what they carry.  If he who pays for the feed is willing to carry the
remailer traffic then he should be immune to pressure.

Hal Finney
74076.1041@compuserve.com

-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBK7SyjagTA69YIUw3AQEVkwP/T6VMZJToUCvNnBTwrYZRKiJarxproRRP
usOFFWyQ27ABBGypS79PfJmJZUyJAuZkAGExEapMTF/Nh0zNb8feZimfJk8A7SbM
5CvlITUMJsjmNCvk/HeeJadhkADyFiD9zRbuZiSzPGNCankt4lCxoGA2qIDklBYp
ZlcMs+eHxbs=
=IT8B
-----END PGP SIGNATURE-----