Re: hash cash and email

We have looked at hash cash for spam, but get stuck on a tangential problem 
- spoofed bounces.  The main catch is that to protect the recipient, the 
server has to automatically bounce non-hash cash messages back to the 
sender and these bounces can be spoofed into spam delivery services.

In a spoofed bounce, I send spam to a recipient on a hash cash email server, 
and I forge the mail to look like it was sent by you.  The hash cash server 
automatically demands payment and bounces the message back to ... you! 
You get the bounce message and look at it to see what happened - voila!  
You've been spammed.

If the server doesn't automatically bounce the non-hash cash messages,
then the recipient eventually has to screen the non hash cash messages
and they are spammed.

So you are spammed if you do and spammed if you don't.


p.s. There are other alternatives worth discussing, but I didn't want to
step on my tag line :-) 

One possibility would be for the recipient's server to hold the body
of the message hostage.  Only releasing it when the hash cash is received.
This is more complex and expensive for the recipient, while it still allows
abuse if the sender automatically pays for hostages.  In this case, the
spoofed sender is tricked into creating the hash cash to pay for the recipient
getting the spam.

The only real workable alternative is for the sender to save copies of
all outgoing mail with the intention of calculating the hash cash if required.
Of course, why not calculate the hash cash in the first place?

But all of this assumes a world where mail clients are primed to use hash
cash and we don't have one of those.  In that case, we merely have to solve
mailing lists...


Received on Tuesday, 1 May 2001 18:39:31 UTC