[hashcash] Re: mailserver support for hashcash [was: response to "proof of work proves not to work"?]
- From: "Eric S. Johansson" <esj@xxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Tue, 25 Jul 2006 12:54:36 -0400
Adam Megacz wrote:
"Eric S. Johansson" <esj@xxxxxxxxxx> 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.
Other related posts:
