At 08:16 AM 3/23/2003 -0700, Vernon Schryver wrote:
Steve Schear <schear(_at_)attbi(_dot_)com> wrote:
> You're still, I think foolishly, focused on an ISP-oriented
> solution. Sender-pays makes them most sense when the client SW is
capable,
> if not singularly empowered, to enforce the payment mechanism at the
> receiving point.
Ok, but what about the main question? What is the minimum speed CPU
that you will allow to send mail? Do you expect everyone from now on
to buy equal speed CPUs?
"Allow"? Stamps will in all probability be "sized" at
60-600GHz-seconds. Whether someone is willing to tolerate this process
delay is one based on CPU speed, patience and importance of the email.
How else do you ensure that the spammers
don't have CPUs that are 10,000 times faster than spam targets?
Why would it matter? The hashcash stamp generation process is highly
asymmetric. Stamps generated through many GHz-seconds of effort can be
speedily authenticated by even cellphone or PDA level machines. Even stamp
generators constructed from state-of-the-art ASICs are unlikely to make
stamps more economically than a cluster of x86 blades.
> >There are reasons why after at least 6 months the hashcash proposals
> >are still only ideas.
>
> The reason is mostly that there are lots of arm chair generals but fewer
> competent programmers.
I can't disagree; standards committees, netnews groups, and bars are
always filled with non-players eager to tell the players how to play.
However, a willingess to admit and deal with fundamental design problems
such as the span of real CPU speeds is part of being a competent
programmer. At the end of the day, competent programmers are those
who have programmed competently. How is your sender-pays implementation
working? How much of your incoming mail is sender-paid, and how much
is simply whitelisted? (If I'm confused about which solution you have
implemented, please forgive me and say how it is working.)
Only about 1% of the spam sent my way gets through my filters, but I
must admit that the DCC is applied to only the leavings of my static
filters.
The following is an edited version of cross-posts from "Eric S. Johansson"
<esj(_at_)harvee(_dot_)org>, Camram's primary developer:
One of the systems proposed in camram is to switch from proof of work
stamps to signed messages once you have been properly introduced. This some
write-ups on this on the camram site but it's kind of obscure because the
idea wasn't well thought out when I wrote it. The paper at
http://harvee.org/camram/ is somewhat more illustrative but it's not fully
documented yet. That is yet another way folks on the cypherpunks lists can
help. Work out a system by which message has an embedded public key and the
key is considered "good" after some introduction process involving two
parties e-mailing each other. Then figure out how to deal with new key
introductions if the original key has been lost to accident or deliberate
action. It's a hoot. ;-)
it is safe to assume that these keys will not have any pass phrases because
this is a crypto system totally invisible to end-users. Argue with me on
the no pass phrases requirement directly if you wish.
the camram protocol can be embedded: at the client, or at the server. I
have a mostly working version at the server and could use some help with a
few things (see end)
one thing folks aren't too aware of is that I have incorporated a Bayesian
style filter into the camram environment in order to reduce the number of
"postage do" notices. As many folks justifiably point out, if you don't
eliminate the need for a "and then the universe changes" step, you won't
get out of starting gates. The addition of a filter to discriminate e-mail
into three categories (red/yellow/green) allows me to reduce the number of
challenge messages to a small fraction what they could be. The feature that
implements "and friends fly free" allows you to build your communications
map and reduce the need for stamps in either direction. Again, this works
at client side or server side.
What I want is
- a Eudora plugin to check for hashcash stamps, send bounce messages, auto
generate my hashcash stamps, and help create and maintain my white list.
- a web site which offers a hashcash stamp generator applet and simple
instructions for
Figure out how to make Eudora interface with Python code and we are most of
the way there.
what we have done:
- basic filter sequence consisting of stamp, white list, postage due
response, basic template
- a stamp generating SMTP proxy prototype.
- spam discriminator prototype based on CRM114
- holding area management for spam and maybe spam mail
- prototype CGI for holding area operations (discarded because UI sucks eggs)
- prototype CGI for browser based stamp generation in response to postage
due notice
what we need help with:
- holding area operations CGI. Must be simple UI allowing non-computer user
to correct discriminator mis-recognitions and release improperly filtered
messages.
- better CGI for browser based stamp generation.
- better SMTP proxy for outbound stamp generation (including proper BCC
handling)
- proxies for pop 3
- Most of the code has been written in Python. We're using Java only for
the postage due notice web page. It needs to be rewritten a bit to be only
Java 1.1, show only a big fat button that says "send postage" when it is
done, and probably some other things which I can't think of right now.
any takers?