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

["Patrick J. LoPresti" <patl@curl.com>]

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

> | The sender must include a separate hash for every recipient, whether
> | CC'd or BCC'd.
> 
> But how can you, the recipient, know which hash in a BCC hash list is
> "yours" if there is no disclosure of the recipients list?  You
> can't.

Right, so you have to try them all.  Checking the validity of a coin
is "fast", so this is OK, in theory.  You also need to try every
address which the sender might have used to BCC you, which assumes you
know all of them...  I suppose there might be some hints in the
Received headers to speed all this up, but yeah, it is not pretty.

Then again, it is not disastrous if you miss a message.  It will be a
long time (ha ha) before everybody is using X-Hashcash, so you will
occasionally have to sift through the rejects folder to find some
legitimate messages anyway.

> What about one false positive out of 100 messages?  Can you say "denial of
> service"?  X-Hashcash does not scale.

Well, you get to decide how many bits you require the sender to match,
so you can make it one out of however many you like.

Or am I misunderstanding what you mean?

> Hashcash and X-Hashcash are not the same thing.  Please do not
> confuse the two.

Yup; I apologize.

I think X-hashcash is a creative attempt at a technological solution
to spam.  And for some applications, like a public mailing list, it
might even be practical.  Who cares whether you can BCC ding@gnus.org,
for instance?

It seems unlikely to catch on as a user-to-user filtering scheme;
digital signatures are probably a better approach for that.

 - Pat