[Top] [All Lists]

comments? hashcash based MTA filtering

1999-02-19 16:46:52


I have a proposal for another class of filtering criteria: filtering
on the basis of a token which consumes CPU time to produce as a method
to throttle systematic abuse.

I am requesting comments from this group because it seems the closest
match of IETF topic to "technical solutions to UBE".  I am open to
comments as to how best to progress this technical solution.

I proposed "hashcash", a CPU cost function based approach to
throttling systematic abuse of unmetered internet protocols (eg UBE
over SMTP), in March 97.  Hashcash is a cpu cost function with tunable
cpu cost, based on partial hash collisions (where hash = cryptographic
message digest such as SHA1). ( 
The construct is quite simple and sample code is provided to tinker with.

I think it is mentioned obliquely in the UBE-solutions document at IMC
( as I sent comment on it to the

: 4.3. Filter based on previous acceptance of mail
: A mail client can filter based on whether the user had previously
: accepted a message from this sender.  This happens as the recipient is
: receiving messages. If the sender is new to the recipient, the
: recipient's client somehow "challenges" the sender to prove whether
: the client should accept the message. Some of the types of suggested
: challenges include just a response, a response that takes
: computational power (computing a problem given in the challenge), and
: monetary payment.

The "response that takes computation power" is a reference to hashcash
I think.

A (20 line) description of hashcash (see for better explanation):

The originator is required to send with email a costly to compute
token bound to that resource name.  Example: Coyote emails Roadrunner,
he computes a hash collision on "roadrunner(_at_)birdseed(_dot_)org".
runs a MTA filter rejecting mail without hashcash postage.

The collisions are based on SHA1.  With tuning parameter t set to 16
bits, Coyote must find (by brute force) a string of form
"roadrunner(_at_)birdseed(_dot_)orgXXXXX" (where X is a number), which produces
16 bits of hash collision with the hash of 
Under unix:

% echo -n 'roadrunner(_at_)birdseed(_dot_)org'  | sha1

and try sequentially roadrunner(_at_)birdseed(_dot_)org00001 etc until a sha1
output with the last 16 bits the same is found such as (the faked):

% echo -n 'roadrunner(_at_)birdseed(_dot_)org21345'  | sha1
(the last 4 hex nibbles = 16 bits are the same).

It needs originating support in SMTP clients, and either MTA filtering
or local filtering on the recipient side.

(You can do common sense optimisations such as exemption lists, and
non-expiring free-reply tokens etc. to allow mailing lists to not
require hashcash, and to avoid normal correspondents from needing
hashcash all the time.  And encoding the hashcash in the email

There are lots of different permutations in which one could use
hashcash.  The major problem as identified in the effects table for
the above quoted section in the UBE-sol document is that:

: Some legitimate mail might go unread if the sender does not reply to
: the challenge. All initial contact will also include challenges,
: which might make the original sender less interested in
: communicating with the recipient.

The problem is of deployment: 5% of people using hashcash is
problematic because lots of bounced mail will ensue.  95% of people
using hashcash would seriously dent a UBE originators volume, and put
pressure on the remaining 5% to convert.  Denting volume won't
_prevent_ UBE people, but it will make them think about targetting
people who are likely to be interested.  A good solution I think.

The problem is how to get from here to there.  One suggestion might be
to have a cut off point.  Jan 2003 turn it on, before that deploy it.
But how realistic is it to achieve that.  Not very probably.