From: lull@acm.org (John Lull)
Date: Sat, 13 Jan 1996 09:22:24 +0800
To: Alan Olsen <alano@teleport.com>
Subject: Re: Novel use of Usenet and remailers to mailbomb from luzskru@cpcnet.com
In-Reply-To: <2.2.32.19960113002203.00906fc0@mail.teleport.com>
Message-ID: <30f70156.4588701@smtp.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


On Fri, 12 Jan 1996 16:22:03 -0800, Alan Olsen wrote:

> At 10:25 PM 1/12/96 GMT, John Lull wrote:
> >On Fri, 12 Jan 1996 10:55:12 -0800, you wrote:
> >
> >> Cypherpunks:  is there any way to respond to, or prevent, this sort of
> >> attack short of actually shutting down the remailer?  
> >
> >Yes, very simply.
> >
> >The remailer could calculate a hash for the body of each encrypted
> >message received (the same portion which will be decrypted by PGP),
> >tabulate the last few thousand hashes, and simply discard any messages
> >with a duplicate hash.  The target of the attack would receive only
> >the first copy of the message.
> 
> I am afraid it is not that simple.  Remember that the mailbombing consists
> of many, many horny little geeks responding to a single message.  They are
> replying to the same message (and probibly adding a few "me too!" lines),
> not mailing the same one over and over again.

The specific attack referred to had an entire encrypted message, not
just a reply block.  Obviously this solution does not work if only a
reply block is encrypted.

> Another idea would be to keep a md5 (or other) hash list of the reply block
> used and have a disabled list for such spam attacks.  (Unfortunatly this
> requires code, thus time.)

Even worse, it requires manual intervention for each attack unless you
are willing to add reply blocks to the list based simply on the volume
of messages using that reply block.  That could prevent the remailer
network being overwhelmed, but is not likely to be seen as adequate by
the target, who would likely still see the first several dozen
messages before the specified threshold was reached.

There is another related solution for the attack using just a reply
block, however.  The final remailer could collect messages either
using a given reply block, or addressed to a given address, if more
that a few were received in a relatively short period of time.  It
could then forward the first half-dozen or so, along with a note that
another X thousand messages were waiting, and asking if the intended
recipient wanted them forwarded or trashed.

Unfortunately this would not prevent the remailer network from being
overwhelmed.  Perhaps some combination of these solutions would be
required -- rationing based on the reply block at each remailer, and
collection & recipient notification at the final remailer.