REMAIL: cypherpunks strategy

We must address a strategy question before it jumps on us.  Do we want to be
yet another "this remailer exists, let's stomp on it" whipping boy, or will
another tactic be more effective?

I have the following suggestion.  Do not announce our cypherpunks remailers
right away.  This is not the right time.  Instead, announce that we intend,
at a later date, to install remailers which are "friendly" in the sense that
they use a special header line, but which will be not be able to be shut down.

[ My suggestion for how to do this:  encourage thousands of users who
support anonymity to run the software, and make it easy for them to
do so.  Then, thousands of users must be kicked out in order to prevent
remailers being available! ]

But, here's the important part, DELAY RELEASE until after a waiting period.
The delayed release is intended to allow concerned network sites and
individuals to install filters for these messages, and to allow users the
time to discuss this (and, for instance, to voice their objections to
catch-all anonymity filters at the news-relay level).  It also prevents
our opponents from achieving a sense of "something must be done" urgency.

My goal is to push a particular policy -- remailers which add a header line
and end-user filtering based on that header line -- as an interim solution
until more sophisticated techniques come into use.  Discussion is also
welcomed on exactly what kind of setup we should be trying to encourage.
This is my current cut at it.


-- Marc Ringuette (mnr@cs.cmu.edu)

> We must address a strategy question before it jumps on us.  Do we want to be
> yet another "this remailer exists, let's stomp on it" whipping boy, or will
> another tactic be more effective?

It depends on the location and setup of the remailer(s).

> [ My suggestion for how to do this:  encourage thousands of users who
> support anonymity to run the software, and make it easy for them to
> do so.  Then, thousands of users must be kicked out in order to prevent
> remailers being available! ]

Thousands of users are not enough.  If individual users are doing it,
they are too subject to pressure from their system managers.  We don't
have software capable of rerouting among a thousand remailers, 100 of which
get their accounts canceled daily, 100 new ones added each day.  We
aren't likely to get it soon, either.

To permanently restore at least last month's level of service, we need
a couple of dedicated, firewalled, buttressed sites.  You want a few
geographically separated people who own their own systems (or who own
or run the company that owns them), who have solid network links
(possibly redundant), and who are fully committed to the idea -- as
committed as funet.fi to persist past the vilification and harassment
and threats.

And those people need backup from the rest of us -- legal help if they
need or want it, money to pay the networking bill if things get tight,
loans of backup equipment during failures under load, system
administration when folks try to break in and trash their machines,
software creation and maintenance, advocacy, policy work, advice, and
a bunch of shoulders to cry on and warm words of encouragement.

Three to five people providing such setups, in collaboration, would
wedge a steel-toed boot so firmly in the door that it couldn't be
slammed by any dyspeptic "net god".

Are we up to this job?  If not, let's scale back what we're trying to
do.  I'd rather succeed at raising consciousness on the issue for a
later try, than try now to set up such a beachhead and fail at it.

	John

> Thousands of users are not enough.  If individual users are doing it,
> they are too subject to pressure from their system managers.  We don't
> have software capable of rerouting among a thousand remailers, 100 of which
> get their accounts canceled daily, 100 new ones added each day.  We
> aren't likely to get it soon, either.

Agree 100%.

> To permanently restore at least last month's level of service, we need
> a couple of dedicated, firewalled, buttressed sites.  You want a few
> geographically separated people who own their own systems (or who own
> or run the company that owns them), who have solid network links
> (possibly redundant), and who are fully committed to the idea -- as
> committed as funet.fi to persist past the vilification and harassment
> and threats.

Uh... I'm not so sure FUNET (the Finnish University NETwork) would agree
with you ;-)

But the truly overwhelming response in support of anon.penet.fi (I still
get flooded by notes of sympathy and support) on the net seems actually
to make a difference, as does effort of prominent personalities (especially
Peter Honeyman) to contact the Finnish autorithies. After talking to
them today, I might actually risk putting up the service again. But I
feel that to ensure that this is the last time the net.demigods try to
close down a server like this we should do our best to address their
concerns. This way, everybody saves face, and we might get a lot of
brownie points.

So what I would like to suggest is that I announce that anon.penet.fi
mark II goes on the air - let's say April 15th, with slightly changed
policies and with all the technical improvements we've been discussing.
And meanwhile I set up an adress for receiving sugestions on
improvements (both technical and political), and encourage newsgroups to
do polls on allowing or disallowing anonymity in that particular group.

But before doing anything, I really would like to get comments, views
and ideas from all of you!

> And those people need backup from the rest of us -- legal help if they
> need or want it, money to pay the networking bill if things get tight,
> loans of backup equipment during failures under load, system
> administration when folks try to break in and trash their machines,
> software creation and maintenance, advocacy, policy work, advice,

Couldn't agree more. If I go for anon.penet.fi Mk. II, I really want to
replace the current mess of shell and awk scripts with something more
efficient (linear search of a 0.5 meg database isn't very speedy...),
and I really would like to have code to check that the incoming SMTP
message actually comes from and existing site, and so on - so there is a
lot of coding to be done that I really could use some help on!

> a bunch of shoulders to cry on and warm words of encouragement.

Yes! I don't know how to express how important the support has been! You
really have to be a stubborn, crazy bastard to do anything like this,
but the hate mail still wears you down if you don't get a kind word of
encouragement every now and then. I really have to thank all of you for
your support!

> Three to five people providing such setups, in collaboration, would
> wedge a steel-toed boot so firmly in the door that it couldn't be
> slammed by any dyspeptic "net god".

Well, looking at the way the discussion is going all over the net, I
think we might be almost there already!

	Julf

>Instead, announce that we intend,
>at a later date, to install remailers which are "friendly" in the sense that
>they use a special header line, but which will be not be able to be shut down.

An excellent tactic, I think.

>[ My suggestion for how to do this:  encourage thousands of users who
>support anonymity to run the software, and make it easy for them to
>do so.  Then, thousands of users must be kicked out in order to prevent
>remailers being available! ]

Automatic installation is key.  (Just as it is for anonymity
filtering!)

I have some comments on automatic installation.  In all cases, make
sure the shell can execute the filter before changing the .forward
file in any way.

Case 1.  The .forward file doesn't exist.  Easy.  Just write a new
forward file pointing to the software, "| remailer".  The remailer
must know how to deliver mail in this case.

Case 2.  The .forward file already points to a filter.  The
implementations of .forward that I have seen accept multiple pipe
commands.  Therefore if the .forward previously said "| <filter>",
rewrite to "| remailer | <filter>".  When the remailer handles a
message, it won't pass any output along the pipe.  Thus for remailed
messages, the filter is never invoked.  Thus the remailer looks
transparent.
	
Case 3.  The .forward file points to a name.  Rewrite the .forward
as "| remailer | mail <old_name>".

Someone who knows more about writing portable shell scripts between
Sys V and BSD should tackle this one.  If we can get auto-installation
to work, we'd lower one of the larger hurdles there is right now.

>But, here's the important part, DELAY RELEASE until after a waiting period.

Not to mention, it gives us time to design and write the code.  This
looks like a good use of vaporware as a political tool.  :-)

Eric