Re: Making Remailers Widespread

[dlv@bwalk.dm.com (Dr.Dimitri Vulis KOTM)]

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.

---

<a href="mailto:dlv@bwalk.dm.com">Dr.Dimitri Vulis KOTM</a>
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps