Re: [Asrg] 6. Email Path Verification (hashcash benchmarks)

Jonathan Morton explained:

> Actually, let's step back a bit.  The original question was whether this 
> was going to be (even approximately) workable on low-end machines, like 
> the old Macs I mentioned.  I think we've established that it's 
> moderately painful, but yes it's workable, as long as we don't need more 
> than 20-bit hashcash anytime soon.
while it would be nice to stay at 20 bits, I suspect that the real initial value 
should be somewhere around 22 bits may be even 23.  This does put quite a strain 
on low-end machine users but I think it's a manageable one as we have discussed.
I do appreciate to your concern for the low-end user.  However, I believe they 
are a fringe user population.  I understand quite clearly what it means to be a 
fringe user and not get any support from the mainstream.  I am disabled courtesy 
the qwerty keyboard.  I an extremely dependent on speech recognition computer 
use.  There's precious little support for my kind of disability in computer user 
interface and even less for speech recognition on Linux.
So, I have found ways to work around the lack of accommodation.  so will people 
with low and computers.  And I am sure, we will try to help by designing the 
right kind of services etc.
> Suppose we implement a "postage required" callback to promote awareness 
> in the early stages.  What happens when one of these callbacks hits a 
> listserv that doesn't know about it?  AFAIK, most listservs will 
> probably interpret it as a bounce, which is probably counterproductive.
this is part of what I was writing up in the hashcash best practices ID.

The way camram accommodates the real world is to provide multiple levels of 
filters.  The first stage is the postage check, second stage is the white list 
check, third is a Bayesian style discriminator.
The third stage is important because it lets me split e-mail into three 
categories (red, yellow, green).  Green is good and passed to the inbox.  Red is 
bad and passed to the dumpster.  Yellow is the e-mail which is indistinguishable 
from Spam[1].  The camram system will send out postage due notices to the 
originators of yellow mail.  From that action, we can further refine which 
messages are spam by paying attention to how the connection is rejected.
after receiving a postage due notice a user can then generate postage in their 
browser courtesy a Java applet and deliver the stamp allowing their message to 
be delivered.  In the document I am working on, I with the issues of forgery and 
spoofing and ways to deal with them.
> Also, what's the best way to combine hashcash and authentication?  Not 
> forgetting, of course, that we still need to have lots of backwards 
> compatibility that can (very gradually) be phased out.  It would be nice 
> to be able to avoid hashcash for initial communications in certain 
> situations, because that lets some of the low-end users off the hook, 
> but that has to be watertight.
does it really need to be watertight?  Is authentication a good idea?  one of my 
starting points for an antispam system is:
    Any measure for stopping spam must ensure that all non-spam messages
    have a means for bypassing that measure to reach their intended
    recipient.

another is that an antispam system must never become a tool for censorship.

If an authentication system has the properties of being able to silence a 
spammer by revoking their credentials, then you have created a tool by which 
anyone can be silenced.  This means you can be silenced.
Imagine how effective we would be against corporate interests if they could use 
the DMCA to revoke your ability to send e-mail.  That is what authentication 
systems buy you.  It is a system enabling censorship.
I'm probably going to get pilloried for this but like it or not, spam is speech 
in the same way that naked breasts on a dancer, Johnny Ashcroft Patriot act 
roadshow, burning a flag of any country, and even yelling fire in a crowded 
theater is speech.  But with all speech comes costs.  Free is not equal $free$ 
and if you're willing to bear the cost, you can make the speech.  At the same 
time, part of the freedom of speech is the ability to be heard but you cannot 
force others to listen.
The more we can follow that model of speech, the closer we will be to a good 
antispam solution.  For example, if we can push the cost of spam as much as 
possible onto the backs of the spammers, we will make unprofitable for the vast 
majority of them.  Then we can watch and learn how to make it more expensive for 
the rest of them.
when analyzing antispam systems, ask yourself "who pays".  With authentication 
systems that I've seen, typically it's increasing the receiver costs for 
decreasing freedom.  Only decentralize systems minimize user costs as a rule and 
have decent reliability in a whole bunch of dimensions.
Personally, I believe that Spam will never go away.  There will always be some 
form of organization which will pay the cost and mass mail.  That's why there'll 
always be a need for personal blacklisting so folks can say "I don't want to 
hear that" and make it stick.  The trick will be making the human interface so 
drop dead simple even your grandmother can't screw it up or at least you can 
unscrew it when she does.

> Finally, as an interim solution, can hashcash be effectively used as a 
> filtering modifier?  Take SpamAssassin, for example, you could subtract 
> a point from the spam score, for every bit of hashcash after the first N 
> (say 16).  That'd be handy for people who keep getting caught by the 
> filters for reasons beyond their control - it gives them a "get out of 
> jail" card, cheap for low-volume mail, expensive for bulk.
you really should take a look at the camram code in CVS.  Much of what you 
suggest is already done.  It may not be exactly as you envision it but 
functionally its equivalent.  Now I just need some Java talent to help me finish 
with the browser postage due applet.
---eric


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg