1997-08-03 - Re: non-censorous spam control (was Re: Spam is Information?)

Header Data

From: Paul Bradley <paul@fatmans.demon.co.uk>
To: Jeff Barber <jeffb@issl.atl.hp.com>
Message Hash: 9f524d880cfed89d4b3cc12356966cd33607f53c1cd0141c9317946ece6e89c1
Message ID: <Pine.LNX.3.91.970803122332.379F-100000@fatmans.demon.co.uk>
Reply To: <199707312017.QAA05673@jafar.issl.atl.hp.com>
UTC Datetime: 1997-08-03 14:56:56 UTC
Raw Date: Sun, 3 Aug 1997 22:56:56 +0800

Raw message

From: Paul Bradley <paul@fatmans.demon.co.uk>
Date: Sun, 3 Aug 1997 22:56:56 +0800
To: Jeff Barber <jeffb@issl.atl.hp.com>
Subject: Re: non-censorous spam control (was Re: Spam is Information?)
In-Reply-To: <199707312017.QAA05673@jafar.issl.atl.hp.com>
Message-ID: <Pine.LNX.3.91.970803122332.379F-100000@fatmans.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain

> > I agree.  If charging for mail would eliminate spam, then I should not
> > be getting the mailboxfull of physical junk mail I receive every
> > morning.  Postage benefits the MAIL CARRIER, not the recipient, and it
> > is in the best interests of the mail carrier to carry MORE mail, not
> > less.  So, e-postage will almost certainly cause more spam, not less. 

Hashcash is a more elegant and simple solution to UCE: most UCE is sent 
by small companies looking for a cheap way to get big exposure, they 
aren`t going to have the hardware to generate partial hash collisions for 
every address they want to mail, it would be prohibitively expensive for 
them to buy fast hardware to generate the collisions. Of course large 
companies who can afford to buy, or already have, mainframes will be able 
to send UCE, but most large companies are smart enough to realise that 
with the response rate gained from UCE, the reputation capital lost 
through sending it, and the valuable mainframe time used to generate the 
hashcash, it all adds up to a big shit sandwich.

Adam Back:   I haven`t read the hashcash paper/description for a while, 
can you give us some figures on how much processor time is required to 
generate hashcash for a 10,000 recipient spam, for n recipients?

Sudden and very exciting idea:

What if we could find a way to make the amount of hashcash required grow 
exponentially with the number of recipients? Of course the spammer could 
then find the optimum number of recipients and divide the list of 
addresses to be spammed into blocks of that size but that is a waste of 
sendmail time, also a waste of bandwidth and the overall time would 
probably still be prohibitively high.

        Datacomms Technologies data security
       Paul Bradley, Paul@fatmans.demon.co.uk
  Paul@crypto.uk.eu.org, Paul@cryptography.uk.eu.org    
      Email for PGP public key, ID: FC76DA85
     "Don`t forget to mount a scratch monkey"