From: dlv@bwalk.dm.com (Dr.Dimitri Vulis KOTM)
Date: Fri, 28 Mar 1997 08:22:12 -0800 (PST)
To: cypherpunks@toad.com
Subject: Re: remailer spam throttle
In-Reply-To: <199703280354.VAA03151@manifold.algebra.com>
Message-ID: <TH804D2w165w@bwalk.dm.com>
MIME-Version: 1.0
Content-Type: text/plain


ichudov@algebra.com (Igor Chudov @ home) writes:

> Dr.Dimitri Vulis KOTM wrote:
> > 
> > Hal Finney <hal@rain.org> writes:
> > > For example, one idea is to have a list of people who are willing to
> > > receive anonymous mail without questions.  It could be that the remailer
> > > is set up to ask before sending mail normally, but to people on such a
> > > list it doesn't have to ask, it just sends it, because they have given
> > > permission.
> > >
> > > Some people have objected to this proposal because the existence of the
> > > list might give a hint about which people send mail through the remailers
> > > Even though the list is of people willing to *receive* anonymous mail,
> > > it could well be that there is a strong correlation with people who want
> > > to send such mail.
> > 
> > Instead of keeping this list in cleartext, one could keep 1-way hashes
> > of the addresses. Thus a remailer (or anyone) can check whether a given
> > address is on the list, but they can't just go through the list and
> > "investigate" the addresses on it.
> 
> Well, they can compile the list of addresses off of USENET postings and
> such and then compute the hashes of the compiled names and identify
> those that are on the anon acceptance list. Not that it completely
> invalidates the idea, but certainly it is a problem.
> 
> 	- Igor.
> 

That's a valid point.  One can obtain a list of "suspected" addreses,
say, from the subscribers to the cp list(s), and run that against the
hashed lists.

Another feature I really don't like about asking the first-time recipients
to agree to accept e-mail while it's on the reamailer is:

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.


I just came up with another idea which definitely has some holes in it,
but perhaps someone wants to improve on it.

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.

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.

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.

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.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps