Re: hashcash spam prevention & firewalls

[phelix@vallnet.com]

On 12 Dec 1997 22:44:29 -0600, Adam Back <aba@dcs.ex.ac.uk> wrote:

>
>
>I am looking at writing some hashcash
>(http://www.dcs.ex.ac.uk/~aba/hashcash/) based spam prevention
>software.  The motivation for writing spam prevention software is that
>spam is better combatted with technical methods than legal or
>political (we do not want clueless politicians coming in ham-fisted
>and requiring "Internet Drivers Licenses" or anti-spam legislation or
>anything else, such actions will be hazardous for the future of
>remailers, in my opinion).

I fear such draconian measures are inevitable as long as the "lobbying"
group CAUCE is around.  They actively discourage the adoption of technical
solutions; favoring legislation.  And since CAUCE was formed by "Net
people", it will be seen (and spun in the press) as though we actually
welcome such legislation.

[... explaination of hashcash spam prevention deleted...]

>The Right Way to do it perhaps is as an SMTP extension, however I
>consider this impractical in the short term because as far as I know
>there is no SMTP extension plug-in mechanism (other than access to the
>source code, and lots of development time) and because there are a
>large number of mail servers in use, and it will be expensive in
>developer (that's me) time to provide patches for them all
>(exarcebated by the fact that in many cases source will not be
>available).

How does PGP do it with their policy enforcer?

>So these problems leave us scratching around for other more generic
>approaches.  One method is to create a proxy which receives mail on
>port 25 (as the SMTP server normally does) filters examining for
>correct hashcash postage, and bounces if the postage is missing, and
>forwards the mail on to the real SMTP server if the hashcash postage
>is valid.  The real SMTP server would then be set to run on another
>port... say port 26 which is reserved, and have the mail forwarded to
>it at that port.  (You would want to disable non-local access to port
>26 either at firewall or with SMTP server configuration if that is
>possible).
>
>Alternatively run the real SMTP server on another machine inside the
>local network.
>
>A few problems with this approach, firstly it may not be possible to
>configure some SMTP server software to run at ports other than 25.  (I
>know you can do it with sendmail: OOPort=26 does it.)  (If this is not
>possible with a given SMTP server you can still run a proxy by running
>the real SMTP server on another machine inside the network).
>
>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 (modern sendmails can be configured to perform reverse name
>lookups on IP addresses, call ident (ident sucks anyway IMO), or block
>based on IP address or domain, etc.)  Is this kind of thing likely to
>be a big problem?

I don't see why.  Just have the proxy work both ways.  Isn't it possible
for the proxy to keep track of which message came from which address and
relay server requests back to the right user?  (I'm not familiary with how
sendmail works, so I'm probably missing something)

>
>This still leaves open the question of the user generating their own
>hashcash postage.  Again this could be problematic for neophytes.  One
>solution is to include a URL for a web page including a javascript
>hashcash generator -- this means that no new software must be
>installed, the user cut and pastes the generated hashcash into their
>message.

How many of the popular email pacakges have support for plug-ins?
Netscape Communicator is the only package (that neophytes will use) I know
of that doesn't support email plugins.  Perhaps in this case a small proxy
could be installed on the user's machine.  The only thing it would have to
do is generate hashcash for outgoing messages.  

>However things would be a whole lot simpler short term if the mail
>originators ISP created the hashcash for him at the ISPs SMTP hub
>where the user hands off his mail for further delivery.
>
>The main problem with this is that the SMTP mail hub would be
>overloaded by the CPU intensive task of generating hashcash.
>
>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.
>
>Ordinary users who chit-chat backwards and forwards in mail generate
>little added overhead for the hand off SMTP server -- the only
>overhead being to generate say 5 seconds CPU worth of hashcash for
>each new recipient the user sends to.
>
>Then you add some hashcash accounting so that users who overspend
>(consuming more than say 1 minutes CPU consumption on the server in a
>24 hour period have their email bounced with explanation of how to
>generate their own hashcash as a heavy user).
>
>Figures would need tuning to see how they worked out in practice,
>however it seems that it would be feasible to handle the whole
>operation entirely at the sending and receiving SMTP servers.
>

What's the difference between this and simply keeping track of how many
messages each user sends in a 24 hour period and blocking people who are
obviously spamming?

-- Phelix