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`
participants (3)
-
Adam Back -
Antonomasia -
Bill Stewart