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