[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making Remailers Widespread


On Fri, 27 Sep 1996, Bill Stewart wrote:

> I've been thinking about how to make one-way remailers a 
> widespread commodity, rather than the novelty item they are today.
> Doing two-way remailers would be better, but that's still a hard problem,
> and I don't want to widely deploy shoddy two-way-remailers.
> Suppose we add form-based remailer support to a popular SSL-equipped
> HTTP server, such as Apache-SSL, by putting remailer.pl and a 
> remailer form in the default setup, which would deploy hundreds of remailers
> with minimal effort.  What would we have to do to make it work well,
> rather than turn into a public relations disaster and spam explosion?

In addition to all the points made below, security would be extremely important
for a remailer cgi script.  If security holes were found in the source code,
it might discourage many web admins from running the script even after the hole
is patched.

> - The remailer script would have to add disclaimers at the beginning
> and/or end of the message reminding readers that the message is
> anonymous, and to contact the remailer cabal rather than the postmaster.
> - Blocking becomes a big problem - it's annoying enough now,
> when there are a small number of remailers with hard-working operators;
> we'd need some sort of automated blocking support to make it
> usable by relatively non-involved operators
> - A centralized block list (e.g. http://www.remailer.net/block.txt)
> which all of the form-based remailers could load and reference would
> allow non-picky operators not to have to handle it themselves
> - Implementing the blocking list as a web form for people who
> want to be blocked would make it relatively painless to use;
> remailer-operators wouldn't have to transcribe email from the
> remailer-operators list to use it, which helps with other problems.

Since maintaining a block list is probably one of the most time-consuming tasks
involved with operating a remailer, it would be a Good Thing to add an option
to the remailer cgi program to operate as a "middleman" remailer.  This would
only require the remailer operator to add or remove entries from a list of
allowed destinations.  The operator wouldn't have to deal with disclaimers and
would only receive complaints from other operators if the remailer is
malfunctioning in some way.

> Technical question:
> - How do we initiate an http or https PUT from a script?
>         I assume there's probably some perl add-in for posting http/https?
>         Is there a command-line-shell interface that can fetch URLs?

I don't know if any perl modules or *.ph files exist that implement http/https.
Http should be pretty easy, but https would require SSL code.  I think there
are perl modules that contain crypto functions, so https could use the
functions provided in the module.  Netcat can be used pretty easily to fetch
URLs (e.g. echo "GET /foobar.html HTTP/1.0" | nc www.webserver.com 80).  This
will print out the HTML files and cooresponding MIME headers on stdout.

- -- 
PGP encrypted mail prefered.
Key fingerprint = d61734f2800486ae6f79bfeb70f95348

Version: 2.6.3
Charset: noconv