Re: mailserver support for hashcash [was: response to "proof of work proves not to work"?]

Adam Megacz wrote:
> "Eric S. Johansson" <[email protected]> writes:
>> model of stamp usage and why it has relatively low load.  Then I'll
>> append to it a summary of rebuttals to the proof of work doesn't work
>> paper.
> 
> I would be very, very interested in linking to this paper once it is
> posted.  Please let me know how it goes.
> 
>> I should point out however that we need people to write code.
> 
> That's what I do.  I've written what I believe is the only serious
> open source Java mail server (I *still* can't find any other that

that is very cool.  It's really hard work to do a good mail server and 
I'm always happy to see another one show up.  Too many of the current 
"bag of parts" mail servers just don't work right in many corner cases.

> I would really like to build in support for a hashcash style
> proof-of-work and set it "on by default" for new installs provided
> that:
> 
>   1) The protocol is standardized, and there is a reasonable consensus
>      that the standard will become dominant

think of it a different way.  If we (i.e. people on this mailing list) 
agree to a standard, and have multiple implementations (your server, 
camram, add-ins for spam assassin and TDMA) then we will have a standard 
by default.  Don't take any crap from any techies come lately whose only 
apparent purpose is to make us waste time and energy.  If there is a 
valid flaw, obviously should fix it but but we should keep focused on 
selling the message.

On practical issues, I think that we may want to consider using multiple 
stamps to reduce the variability of time of calculation.  Yes, each 
stamp is fairly big but what the heck, it's all for good cause.

on the stamp size feedback mechanism, we can't have that without also 
having some high-quality "this is spam" mechanism that any plumber could 
use without trouble.  The reason I say this is because in the early part 
of adoption, if you advertise you have a capability that can be 
overwhelmed by significant force, this makes it easy for the attacker to 
target you.  If stamps are overwhelmed, geeks will say "stamps are 
obviously no good", and discard proof of work systems.

therefore, we need to come up with a strategy of handling stamp adoption 
in the early phase without making it trivially easy for spammers to 
overwhelm.  One possible solution may lie in the brown list logic.  If, 
instead of a simple blacklist, we use an assessment of whether a source 
has been mostly green e-mail or red e-mail.  that assessment modifies 
the price of the connection.  This assessment can be created off of the 
output of the content filter.  False positives probably won't hurt too 
badly if there has been any good mail from that site at all.

Once we have an assessment of the sites e-mail quality, the price of 
stamps can go up or down.  But the important thing here is to have that 
feedback mechanism.  If a spammer sends out Green quality e-mail, then 
we must close the loop so that the postage cost can rise.

I'm also thinking on the blacklist assessment, we may want to use a cidr 
block scoring mechanism.  If you can count the number of spam sources 
within a cidr block, that puts some negative weight of the rest of the 
IP addresses in that range.  I'm not exactly sure hope this would work 
but it's a rough thought.


> 
>   2) There is a good, solid, well-written, professional-looking,
>      *sound* rebuttal to "proof of work proves not to work" that I can
>      point to when people complain about spammers and zombie machines
>      making the whole thing pointless.  Ideally it should include
>      calculations at least as detailed as the paper it's rebutting.


I think I'm going to have a little more time.  I just had a self funded 
start up go south and because of the self-funded part, I am looking for 
more consulting projects[1].  But in the meantime, I can probably make a 
draft of the paper.

---eric

[1] a project I was going to do before, well you know, was a 
decentralized mailing list.  Think USENET but instead of a fixed set of 
peers that you talk with, you use a random selection of peers who in 
turn cascade the message to other peers.  Each message carries a list of 
who it's been to which reduces the list of possible destinations.

The anti-spam component would be that the message injector generates 
fairly large stamps and everybody else generates somewhat smaller 
stamps.  Although this would become part of the audit trail all the way 
through to the end recipients.

They're obviously would be control messages for sign-up, sign off, 
banning (i.e. if you are a complete and total asshole and everybody 
wants you off the list)

it's incomplete but that's basically the idea.  It would be very cool 
culturally and, just maybe, a simple enough and self-contained enough 
solution using proof of work systems that we could get some cultural 
credibility.