Re: Idea for alternative hashcash/antispam implementation.

> The only negative thing I can come up with at the moment is that it
> requires an SMTP-protocol update in order to work.

Which, unfortunately, is a very large point against it.  Namely, it 
appears to require all legitimate senders to update their MTAs to 
support the newly modified protocol.  Therefore, you might as well 
replace SMTP wholesale, which we already know isn't going to happen.

Another question worth asking is:  What does it save versus checking 
hashcash after receiving the message?  Bandwidth and a bit of storage 
is the answer, but neither of those are expensive resources in most of 
today's Internet (at the MTA level, not necessarily client level).

However much we'd like it to be, hashcash by itself does not make an 
anti-spam scheme.  Initially at least, the best places for it to work 
are as a false-positive mitigator (in conjunction with a content filter 
or DNSBL) and/or an introducer (in conjunction with a whitelist).  I 
have in development a scheme which explicitly combines both of these 
approaches, and Eric has something broadly similar in CAMRAM.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email protected]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.