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.  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).

(Hashcash is a way of proving that the sender has consumed a tunable
amount of CPU time.  The verification process consumes negligible CPU
time.  This allows us to require the would be spammer to spend say 20
seconds per mail, which will slow him down considerably, over his
current tactics of 1000 long Bcc lists allowing him to hand off
spamming tasks to mail servers.)

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, and b) it reduces bandwidth consumption on
dial up users pay per second lines as the spam is killed before they
see it.

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).

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?

Another approach is to try to hook in a hashcash SMTP proxy filter at
the firewall.  I am not that familiar with firewalls.

Anyone have thoughts on the sorts of filtering you could install at
the firewall level, and how portable this would be based on installed
base of types of firewall?  (ie It is not interesting if you can do
nifty proxy functions with foobar firewall software if it is used by
<1% of sites, and the function is impossible with other firewall
software).

The required filter functionality is something like this in order of
desirability:

Accept the SMTP session.  Use an EHLO extension HASHCASH to say that
this server expects hashcash.  (Extended HELO is a method of
specifying SMTP extensions (I think)).  Accept the headers, and if a
valid hashcash postage is not included, hand off to the real
mailserver a site configurable bounce message.

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.


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.

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.

Comments?

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`