REMAIL: cypherpunks strategy

[Eric Hughes <hughes@soda.berkeley.edu>]

>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