From: dlv@bwalk.dm.com (Dr.Dimitri Vulis KOTM)
Date: Fri, 28 Mar 1997 19:25:40 -0800 (PST)
To: cypherpunks@toad.com
Subject: Re: remailer spam throttle
In-Reply-To: <199703281917.TAA03495@server.test.net>
Message-ID: <DVVa5D47w165w@bwalk.dm.com>
MIME-Version: 1.0
Content-Type: text/plain


Adam Back <aba@dcs.ex.ac.uk> writes:

> > 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.
>
> Here's a partial solution to that: in the ping email informing the
> recipient there is mail waiting, you include a key, encrypt the
> message body that you are retaining data with the key and then discard
> the key.  Give a deadline: "your message will be deleted in 5 days".
> They re-supply the key when they request the message.  You immediately
> decrypt and send it back to them, discarding all knowledge of them
> (email, encrypted message, encryption key).

That's a good idea, but it'll take up a lot of disk space at the
machine running the remailer.  Right now, remailers that provide
latency don't keep an e-mail for more than about 12 hours. Once
you start keeping them around for a few days (a reasonable grace
period for a first-time user), it's a lot more disk space.

> One snag is that you still have addresses for recipients on your
> machine so they can go harass people and ask them for the keys to the
> as yet uncollected messages.
>
> Refinement to solution (I like this one), get rid of the intended
> recipients address immediately after sending the ping, just keep the
> encrypted body of the message.  Include in the ping something which
> reliably selects a message (say first encrypted line, SHA1 hash of
> encrypted message, whatever, to save you having to try to decrypt all
> of your messages).

That's a good refinement, but it's still not enough, IMO.
Suppose a LEA wants to search the computer hosting the remailer.
They come across a bunch of encrypted files.
The operator has to convince the LEA that they don't have the means
to decrypt the e-mails or even to figure out who they're from.
That just may be close to contempt of court. Say, you might be
asked to explain how you generate the "random" keys so they
can be recreated.

IMO, the 'net has changed from what it used to be a few years ago.
One can no longer send e-mail to an unknown recipient and hope that
they're willing to accept anonymous e-mail. I'm not 100% sure what
needs to be done, but I firmly believe that in today's climate
unless the remailer knows that the recipient took some positive
action to indicate that s/he has a clue (such as, added a key to a
keyserver), their anon mail should be immediately discarded and
they should instead get a note:

Someone tried to send you anonymous e-mail; because we don't
know whether you want to receive anon e-mail, it's been discarded
and can't be recovered; anon e-mail can be bad; disclaimer
dislciamer disclaimer; and here's what you need to do to
receive future e-mail if you want it.

> > [keyserver with I-accept-anon-email bit consulted by remailer, no
> > key in remailer => instant trash of message and ping message
> > explaining how to accept anon email]
>
> This sounds a lot like the distributed block and accept list idea
> which has been discussed a bit.

Yes - nothing really new.

> I like your treatment of the remailed material as a `hot potato',
> instantly pass it on or burn it.

Yes - 5 days worth of anon mail, even if it's encrypted and the
recipient is stripped, is an attractive target for LEA's looking
for child porn and the like.

> > 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.
>
> The per remailer block list system kind of does this at the moment,
> only the list of people initially marked down as willing to accept
> anon email is the world.
>
> Everyone can recieve email, but people get blocked when they complain.

Unfortunately this model is based on assumptions that are no longer
true.  I've been on the 'net since the early 80s.  I used to
prozelityze(sp?) everyone I knew that the 'net is a great tool
and that  we all should use it. Well, now the 'net is full of
assholes and you can no longer assume that just because someone
has access to the 'net, they have a clue.

However I think it's a safe assumption that someone who put their
key in a key server has enough of a clue to be able to handle
an anon e-mail; and if they don't, they should be able to turn
it off easily.

> Incidentally, it has occurred to me for a while now that the reverse
> problem also exists: if I suspect you (Dimitri) use remailers, I can
> forge a message from you to all the remailer operators requesting that
> I (ie you) be blocked.  I can include some exceedingly dire legal
> threats to the remailer operator, and dig up some vile messages from
> some dark corner of usenet which I falsely claim came through that
> operators remailer.  As the remailer operator doesn't keep logs he
> won't be able to recognize the falsehood of the accusation.
>
> To solve this problem you need to do a ping message, "please reply
> with this nonce to be blocked".

Yes, that's a possibility. E-mail from has has been forged in the
past, as Igor can attest. :-) Again, the 'net has changed. As some
folks are aware, I run 3 mailing lists at another site. 2 are near-dead,
but one has been up since '89 and is pretty active. Recently I had
to institute the policy of confirming subscriptions because of the
several forged subscription requests.  Such things were unthinkable
even 4 or 5 years ago.

A key server presumably has some mechanisms for checking that someone
who wants to store or update a key for a@b appears to be a@b.

---

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