Re: hashcash spam prevention & firewalls

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

> I am looking at writing some hashcash
> (http://www.dcs.ex.ac.uk/~aba/hashcash/) based spam prevention
> software.

> So what we want is a filter to bounce messages without the required
> hashcash postage, we ideally want this to happen at the ISP or
> organisational SMTP server end, rather than at the recipients end,
> because a) it is simpler for 1 service provider to install software
> than 100,000 neophytes,

Hashcash in this context suffers from the 'fax effect' - the
catch 22 of "We won't install what isn't widely used".


>                         and b) it reduces bandwidth consumption on
> dial up users pay per second lines as the spam is killed before they
> see it.

I have not (yet) persuaded demon to allow user-defined procmail rules
on the ISP end of the phone lines.  Anybody know an ISP who does this ?
I'll be with them in days if they match the other services I want.
I can't imagine ISPs installing something at all exotic if they refuse
to use procmail.

> Secondly the proxy approach prevents some of the SMTP server functions
> from operating properly because the process on the other end of the
> socket is our hashcash proxy on localhost rather than the remote mail
> hub

No loss.

> If the postage is valid, replay the headers to the real SMTP server
> (with IP masquerading so that the IP address appears to be coming from
> the originator, so that the SMTP server will not get upset about
> reverse DNS look up mismatches etc).  Then act as a dumb proxy for the
> rest of the connection passing data through to the normal hashcash
> server.

The above paragraph looks like a strange (and IMHO wrong) way to
mix firewall technologies.  If you are passing mail through a proxy
you won't want to either IP masq or lookup DNS records internally.

> There are a few techniques to reduce the overhead of preventing spam
> with hashcash.  One is to require valid hashcash only on the first
> message to a given address.  (Spammers being hit and run types, and
> even having to generate hashcash for each spamee once would be
> expensive for a spam list of 10 million unwilling spam recipients).
> Better, is to require valid hashcash on all mail, _until_ the
> recipient replies to a mail.  This is good because people rarely reply
> to spammers.

This means a huge database of who has replied to whom.  Must the
reply have headers indicating In-Reply-To a recognisable message ?


--
##############################################################
# Antonomasia   ant@notatla.demon.co.uk                      #
# See http://www.notatla.demon.co.uk/                        #
##############################################################

At 12:25 PM 12/13/1997 GMT, Antonomasia wrote:
>Hashcash in this context suffers from the 'fax effect' - the
>catch 22 of "We won't install what isn't widely used".

Makes sense to run it in a permissive mode for a while first -
sendmail++ could add hashcash to outgoing messages, and mark the
hashcash information in the headers on incoming messages.
The catch is getting it generated - you've got to include it
either in ISP's outgoing relays, or ideally in client software.
(Since hashcash is mainly for spam prevention, relays _could_
just check that there's some valid hashcash going by without
removing it - that's a bit tricky in multiple-recipient mail anyway,
since you'd normally need to include one hashcash per recipient.)
So if you want it adopted, you'd need to talk to the folks at
Qualcomm Eudora and at Netscape, and see if you can get Microslush
to include it in some of their mail clients.  This does have the
advantage that most of the CPU load is calculated on users' machines,
where there's plenty of spare horsepower, rather than on relay
machines which are not only easily tricked, but also tend to have
about as much horsepower as each of the thousands of clients they serve.

>>                         and b) it reduces bandwidth consumption on
>> dial up users pay per second lines as the spam is killed before they
>> see it.
>
>I have not (yet) persuaded demon to allow user-defined procmail rules
>on the ISP end of the phone lines.  Anybody know an ISP who does this ?

Almost any ISP that provides shell accounts can give you a mechanism for this,
whether it's procmail itself or your own relay program that feeds
your mail to procmail before delivering it to you.

Alternatively, some of the boring commercial services like AOL
have Spam-blocking options, and the pobox.com mail relay does also.
These aren't like having your own procmail, but they'll kill off
the well-known spammers for you, e.g. blocking c y b e r p r o m o
and some of the popular harvester programs that advertise themselves
in mail headers.



>> Better, is to require valid hashcash on all mail, _until_ the
>> recipient replies to a mail.  This is good because people rarely reply
>> to spammers.
>This means a huge database of who has replied to whom.  Must the
>reply have headers indicating In-Reply-To a recognisable message ?

That has real trouble with mailing lists.
It also creates a valuable soft-target traffic analysis database;
unlike current sendmail logs, it'll probably stick around for
an extended period of time, and be readily subpoenaed.
At a minimum, such a database should keep keyed hashes of addresses
rather than the addresses themselves - that still makes it possible
to check for individual known addresses, but makes it harder
to go fishing for everybody.  The reason for keyed hashes is to
require dictionary attacks to target individual machines,
but the added work factor for hashing the database of usual suspects
for aol.com, compuserve.com, hotmail.com, juno.com, worldnet.att.net,
demon.co.uk, and relay.national.sg isn't that large.

Also, it's easy for spammers to fake replies to themselves to 
prime the pump for their big spam.  And if you let mailing lists slide,
they can easily forge mail from the mailing lists.
				Thanks! 
					Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Bill Stewart <bill.stewart@pobox.com> writes:
> It also creates a valuable soft-target traffic analysis database;
> unlike current sendmail logs, it'll probably stick around for an
> extended period of time, and be readily subpoenaed.

I think I figured out a solution to this nasty problem prompted by
Robert Costner's comments:

How about this alternative which achieves the same functionality and
removes the juicy supeona target:

Turn on hashash database for all mails.  That means hashcash gets put
in the database to prevent double spending.  (If we don't do this
spammers will club together and do one mega-spam reusing the same
hashcash they generated with their spam fest motivated CPU farm and
hit you with spam from many addresses, or all forged as from the same
address or whatever).

So now when you reply to a message, on it's way out via the mail hub,
mark the hashcash token as reusable.  This means that the sender can
cache sent hashcash tokens, and re-use them when after he gets a
reply.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`