From: Hal Finney <hal@rain.org>
Date: Fri, 28 Mar 1997 12:15:36 -0800 (PST)
To: cypherpunks@toad.com
Subject: Re: remailer spam throttle
Message-ID: <199703281941.LAA00237@crypt.hfinney.com>
MIME-Version: 1.0
Content-Type: text/plain


dlv@bwalk.dm.com (Dr.Dimitri Vulis KOTM) writes:
> With the present scheme, if a remailer is "raided", it has precious little
> interesting stuff on it at any one time. Now consider the scenario:
>
> X sends 1000 copies of child porn/seditious libel to 100 people believed not
> to be using remailers right now.  The remailer keeps the 100 e-mails onits
> hard disk and e-mails each receipient a ping, inviting them to agree to the
> disclaimer terms and to retrieve their anonymous e-mail.  The first recipient
> to retrieve the e-mail gets upset and contacts the feds.  The feds figure, the
> remailer still has the 99 other e-mails and the information on who's supposed
> to receive them in its queue; why not seize it and take a look.

This is a potential problem, but there are some other considerations.

First, there is no particular reason why one recipient of some email from
the remailer should know or even suspect that other people have the same
email waiting.

Then, to defend against raids like this, the material could be separately
encrypted to each recipient.  There would be no way to know that material
sent to one recipient matched material sent to someone else.  The raiders
would just find a bunch of encrypted files.

Of course, if it were a sting operation, with the recipients being lured
or entrapped into requesting information they shouldn't, then the sender
might avoid using these countermeasures.  However, there wouldn't really
be any need to use a remailer for a sting operation like this, it could
be done just by offering the material from an ordinary address.

More generally, I think we need to keep in mind what a remailer does and
what it doesn't do.  The essential function of the remailer is to provide
anonymity via mixing messages.  It does not provide confidentiality of
message contents.  That has to be taken care of by encryption.  And,
as I wrote yesterday, it doesn't (can't) keep secret who the people are
who send and receive anonymous mail.  All it can do is to disguise which
particular people send and receive to each other.

The same is true of a DC-net or a perfect Chaumian mixnet.  These systems
do not disguise their particpants, or protect the confidentiality of their
message contents; they only hide the knowledge of who is talking to whom.

Having said that, I do like some aspects of this idea:

> There's a big distributed database of pgp keys on the several keyservers.
> Add a bit to the database specifying whether the key owner wants to receive
> anonymous e-mail.  By default set it to true for the existing addresses.

(The "default true" is going to allow the same kinds of abuse which we
have seen in the past.  Some remailers may be able to tolerate this, but
as we have seen, many can't.)

> When the final remailer in the chain wants to send someone an anonymous
> message, it attempts to retrieve a key from the keyservers.
>
> If it fails to find a key, it junks the mail (you don't want to keep it
> around, it's baiting the LEAs!) and instead sends a notification to the
> recipient that some anon e-mail was addressed to it, but it was junked;
> and if they want to receive anon e-mail, they need to give a pgp key
> to one of the key servers this remailer uses.

This is what I like.  It's a lot simpler than trying to keep a copy of
the anonymous mail and deliver it later when the person asks for it.
Just let him know that someone is trying to reach him anonymously, and
let him enable that if he wants to be able to receive the next anonymous
message that comes in for him.  You can load his permission message down
with all kinds of disclaimers that say he knows he's likely to receive
obscene, threatening and illegal material, that he doesn't mind, that
he knows the remailer is an automated system which doesn't look at the
contents, etc.  Not only does this give you a defense but it makes the
person think about what he's getting into, so he will in fact be better
prepared when something bad comes his way.

Plus, having taken positive action to enable receiving anonymous mail, he
will hopefully be more knowledgable about how to request that you stop,
and it won't be such a big deal.  He opens the pipe, and if he gets a
face full of sewage, he closes up the pipe right away.  You warned him.

> If it finds a key, it looks at the anon mail bit; if it's on, it encrypts 
> the e-mail with the recipient's key and sends it; otherwise it junks it.
>
> Obviously, the key servers would need to be modified to allow users to
> specify whether they want anon e-mail when then store their keys, and
> to change this setting any time.

Key servers wouldn't be the only place to store this information.  I think
the remailer could keep its own list, especially if it were defaulting
to "off".  This way recipients wouldn't have to generate and submit PGP
keys, which is more work than just sending a reply to a remailer giving
the OK to receive anonymous mail.

> Right now, there's a very large number of addresses in the key servers.
> Instantly making them into a list of addresses that accept anon mail
> will make it hard (hopefully infeasible) for the LEAs to investigate
> everyone willing to accept anon e-mail as a suspect in sending it.

More cautious or politically vulnerable remailers might default in the
other direction.  It would be a matter of the individual situation.

Hal