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

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