Making Remailers Widespread

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?

- 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.

- Of course, once anybody can fill out their name and ask to be
blocked, it's possible for spoofers to block people who don't want to be.
One approach for preventing this is to implement a three-way handshake 
        - user fills out form, form mails back blocking notice with cookie, 
                user returns cookie to complete blocking
        - this is a bit messier for mailing lists, but we can ignore...
        - special-case for "postmaster", who may want to block
                all of foo.domain instead of just postmaster@foo.domain
        - special-special-case for postmasters of big sites, e.g. aol, netcom,
                who we may want to ignore?
- A sender-blocking list is harder, and may still take human attention

- remailer chaining - allow user to put in another Apache-remailer site
        so we don't have to limit the chaining to known short list of sites.
        The remailer.pl can send an https foo.bar.com remailer.pl PUT
- The remailer form can probably just have field for second site, if empty
don't use.
        I suppose remailer.pl could also automagically add that in when it
posts.

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?


#			Thanks;  Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# <A HREF="http://idiom.com/~wcs"> 	
# You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto

Bill Stewart <stewarts@ix.netcom.com> writes:
...
> 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.

Unfortunately, one-way remailers have much fewer uses than two-way remailers,
any many of these uses are abusive.

> - 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.

Julf's anon.penet.fi used to add a signature with a disclaimer.

> - 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

Yes.

> - 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

A single centralized point of failure is bad. Maybe 4 or 5 redundant ones.
A blocking request sent to one will be replicated in the other automatically.

> - 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.
>
> - Of course, once anybody can fill out their name and ask to be
> blocked, it's possible for spoofers to block people who don't want to be.
> One approach for preventing this is to implement a three-way handshake
>         - user fills out form, form mails back blocking notice with cookie,
>                 user returns cookie to complete blocking

That's the protocol Eric Thomas's listserver uses to make sure mailing list
subscription requests aren't spoofed. I think I mentioned it recently on
this list in the context of creating a similar blocking list for addresses
that don't want to receive unsolicited commercial e-mail. Indeed, if such
a system is put up, it could maintain several blocking lists:

addresses who don't want any remailer mail
addresses who don't want 1-way remailer mail, but are willing to get
 2-way remailer mail
addresses who don't want unsolicited commercial e-mail (probably a biggie :-)
addresses who will only accept PGP-signed e-mail
etc.

>         - this is a bit messier for mailing lists, but we can ignore...

We can't quite ignore... In the scheme you've just described, someone can
enter a blocking request via a Web page and give a submission request for
some mailing list, and the cookie will be e-mailed to the mailing list.

>         - special-case for "postmaster", who may want to block
>                 all of foo.domain instead of just postmaster@foo.domain
>         - special-special-case for postmasters of big sites, e.g. aol, netcom
>                 who we may want to ignore?
> - A sender-blocking list is harder, and may still take human attention

I don't think it's a good idea to suport blocking receivers in an entire
domain, like *@aol.com. Just say it's not supported.

I don't think it's a good idea to support sender blocking at all.

Would the receiver blocking list be available to everyone to view? That
sounds like a violation of privacy. Someone suggested on this list that
(assuming that the entires are addresses that match exactly, not regular
expressions), one can store hashes of addresses. Then when a remailer
wants to know if a particular address is on the list, it computes the
hash and searches for it (binary search is fast).

A curious person can check whether a particular address is no the list,
but can't obtain the list of all blocked receivers.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

KOTM said:
> Bill Stewart <stewarts@ix.netcom.com> writes:
> > 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.

     While IANAC, maybe a suggestion here (and there might be holes in 
this) when the email is sent to the remailer, it gets a key pair generated,
and one of the keys is inserted into the header of the forwarded email
like this:

*****This is an anonymous message forwared from the spread remailer*****
*****To reply to this message, send email with the following 4 lines**** 
*****as the first part of the message to:                          *****

=>replykey:<key goes here.

     The reply address is encrypted with the other part of the key. It 
isn't real secure, but the server admin can't get the return addresses
without the key. 
    
     Off the top of my head, the biggest problem is that you can't send 
email to a web site (page).

     The other problem is that it would greatly add to the complexity
of the .pl program, and make it take much more overhead. What about
making the one way a .pl script, and the two way a module?       

    
Petro, Christopher C.
petro@suba.com <prefered for any non-list stuff>
snow@smoke.suba.com

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

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.

Mark
- -- 
PGP encrypted mail prefered.
Key fingerprint = d61734f2800486ae6f79bfeb70f95348
http://www.voicenet.com/~markm/

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQEVAwUBMk1apCzIPc7jvyFpAQGHbwgAvWQgQnZXov/u6ts2eVjbOfG0ogNpkhZa
GuZrX+hNoIJNTO+2aqeKIolnz+5rSz+80FH6iOhr96OftilFr4o7Qug2cS4zHijQ
9JBtvbZ6TljDRnogsc6LInbVz/doHr7vbQmCyFslAdo7uAd/cTK1C9X0cHKewepc
eLa1dv7qJWupcIIYy+KvhDAfGPjuhf7Q5fNYlfQlfKzdNk38ZkPEUyqLCypgQ8Hk
CH+wm5ne5EGvztnR7qgyt6XZk6CU3UQBQCfbLICIQMYdUzy/f7hCBmDjVxXXMNc7
iIAQyLG0c0BJNs4wNmFyREmnL7vbmMqwLAKvP9jk0XgRpXzY9K0cUA==
=uLlT
-----END PGP SIGNATURE-----