[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making Remailers Widespread
Bill Stewart <[email protected]> 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
> - 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
> - 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 [email protected]
> - 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.
<a href="mailto:[email protected]">Dr.Dimitri Vulis KOTM</a>
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps