Hi,
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). (http://www.dcs.ex.ac.uk/~aba/hashcash/)
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
(http://www.imc.org/ube-sol.html) as I sent comment on it to the
author.
: 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
http://www.dcs.ex.ac.uk/~aba/hashcash/ 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".
birdseed.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
roadrunner(_at_)birdseed(_dot_)org(_dot_)
Under unix:
% echo -n 'roadrunner(_at_)birdseed(_dot_)org' | sha1
6fc0af015d2b20b545ff44726c6d26e09397d60a
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
af6fb545ff44c0015d2e09ffb20726c6d26fd60a
^^^^
(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
address.)
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.
Comments!
Adam