Re: [ANNOUNCE] contrib/hashcash.el spam fighter

[Simon Josefsson <jas@extundo.com>]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * Simon Josefsson <jas@extundo.com>  on Mon, 24 Jun 2002
> | No, it does not work like that.  Each coin has a limited life length
> | (e.g., 28 days), the receiver only has to keep track of valid ones
> | within the time window.
>
> I-the-spammer generate a new hash every hundred thousand messages or so.
> I-the-spammer easilly circumvent the X-Hashcash system, and without even
> trying hard.

How?  The coin is specific for each recipient, and you can only use
each coin once.  To create a new coin, you need to burn CPU time.  If
you send the same hash in more than one message to the same recipient,
the double spending database will notice and reject it, and if you
send the same hash to another recipient, the other recipient cannot
verify the coin and rejects it.

> | This is explained on the web page...
>
> I looked.  The X-Hashcash scheme is fundamentally flawed.  It relies on the
> sender being honest when he says that he spent the time generating the hash
> when he puts it in his headers.

From how I understand it, the receiver verifies that the sender spent
time generating the coin by verifying the coin, it is not simply
trusting the sender about that.

> | > The more I learn about X-Hashcash, the more I see that it is doomed to
> | > fail.
> | Do you have a better idea?
>
> Hashcash at the MTA level.  That is enforceable because the recipient says
> "find X bits of collision with this hash or your message will not be
> accepted".

This would slow down my mail server a bit, but is otherwise good.  One
good thing with doing hashcash in the MUA is that only my own machine
is slowed down.