Re: deployment & thunderbird (Re: PR Problem?)

decoder <[email protected]> Fri, 10 Nov 2006 12:14:32 +0100
Newsgroups gmane.mail.spam.hashcash
Message-ID <[email protected]>
Adam Back wrote:
> Yes I still think hashcash is a good idea.  Particularly I like the
> plan where hashcash is optional, and helps add positive points to
> avoid spam filter false positives.  It doesnt require infra as you
> noted; and it adds value to both sender and recipient, which gives it
> a plausible deployment path to wider adoption -- incremental value.
> (ie there are a number of systems or approaches which could solve
> interesting problems if only every body would switch systems at once,
> practically that kind of deployment is close to impossible to achieve.)
>
> I dont personally know an thunderbird developers, I guess we can try
> to raise awareness and get even more votes on the feature so that it
> becomes feature request #1.  And/or find a contact who is involved in
> thunderbird development to shepherd and champion the feature even if
> he doesnt implement it on say the thunderbird-developers list.
>
>
> About what Eric said, I agree there are a number of higher order
> things you can do, and there is a paper by Ben Laurie and Richard
> Clayton (see http://www.hashcash.org/papers/ at the bottom) arguing
> that hashcash stamps are not enough to directly make spam
> uneconomical, which lends weight to what Eric is saying.
>
> Higher order things Eric mentioned, like white listing friends,
> contacts, people you reply to so stamps are sent less often (say at
> introduction events only -- email to new contact, until first
> response).  Mixing with reverse-turing (fuzzy images) etc.
>
>
> However personally I think at least at this point just basic hashcash
> stamps would add some value and should be a lot easier to deploy.  The
> code required is small, the stamp verification for example has been
> implemented in bash (using sha1sum), perl, etc and is trivial.
>
> With higher order approaches I think there can be reliability issues
> to work through (though probably fixable) also in doing challenge
> response over smtp due to other mail failures, and to filtering itself
> potentially.
>
> Also I think Ben & Richards paper while very good data, and
> extrapolations from that data, with hashcash one would be increasing
> the costs to spammers.  Realistically one has to assume that you can
> not stop spam -- paper spam which costs several cents to print and 10s
> of cents to post still arrives in volume.  Just it tends to be more
> targetted (ie less complete junk, higher success ratio).  It is the
> low success ratio stuff that is the worst of spam.  Also its a dynamic
> system, spammers will react.  ie if we succeeded in increasing the
> cost, maybe they would start buying accurate demographic data and
> geographic email maps and language maps and sending emails that you
> are in a language you can read, are relating to things you've bought
> before and forgotten to opt out of reselling of marketing info, and
> are of relevance to you geographically.  And actually minting hashcash
> stamps themselves.
>
> So personally I think the fastest way forward is to get hashcash
> verification into as many MTA / filtering / bayesian etc systems as
> possible, and to get stamp creation into as many MUAs as possible.
> Obviously starting with the largest user base, probably starting with
> open source.  SpamAssassin is a good start, but there is also some
> scope to figure out ways to automate its config.  As it stands it
> requires admin to turn it on and config it, as no one managed to
> figure out a way to have a zero-config way to turn it on -- issue is
> knowing the recipients own addresses -- addresses he is willing to
> receives stamps marked as.
>
> While that is ramping up to the level of users that spammers would
> even think about hashcash, one could expand the approach and plugins
> in MTAs, MUAs etc to consider higher order things that Eric explained.
>   
Implementing this at MTA level is not hard. I wrote a postfix content 
filter which stamps all outgoing email but I don't think it is hard 
either to write such a plugin for Thunderbird... When I have more time, 
I'll take a look at some thunderbird plugins and maybe I can derive a 
hashcash plugin from that :D

Best regards,


Chris

> Or something like that :) Anyway lets get a thunderbird plugin
> somehow!  A programming bounty might be another way.
>
> Adam
>
> On Thu, Nov 09, 2006 at 04:48:44PM +0000, DeLesley Hutchins wrote:
>   
>> When I first read about HashCash in 2004, I thought to myself: "What a great
>> idea!  I'm sure someone will add it to my e-mail client soon," and I went
>> happily on my way.  Two years later, the trickle of spam has become a flood, my
>> Bayesian filter is overwhelmed, and... HashCash seems to have vanished into
>> obscurity.  There was a flurry of articles and interest in 2004, a few in 2005,
>> and then... nothing.
>>
>> I was surprised to find that Thunderbird still has no HashCash support.  It's a
>> popular mail-reader, open source, with a plugin architecture. A quick check on
>> Bugzilla shows that the HashCash feature request is in the top 20 (out of
>> thousands!) by number of votes, but nobody seems to be working on it!
>>
>> What happened?  Spam is an ever-more-painful thorn in the side of every computer
>> user, so I would expect to see whole teams of open-source programmers inventing
>> a bazillion different ways of fighting it.  Instead, I see filters, and filters,
>> and yet more filters.  I would have thought that the decision to implement
>> HashCash was a no-brainer.  It's very simple to implement, it has the
>> overwhelming advantage (compared to DomainKeys etc.) that it doesn't require
>> major infrastructure changes, and it can be optionally enabled on a per-user
>> basis.  This is a perfect opportunity for the open-source community to lead the
>> entire industry.
>>
>> As I see it, this isn't a technical problem.  You folks at hashcash.org have
>> written the basic software.  It's been part of SpamAssassin for years.  
>> All we need is client (MUA) support, and it's not your job to integrate it into
>> every e-mail client.  
>>
>> This seems to be a political/PR problem.  I am totally mystified as to why there
>> is so little interest from the authors of e-mail clients.  I assume that you've
>> had many discussions with the mozilla developers and others -- what was the
>> response?  Why the lack of enthusiasm?
>>
>>   -DeLesley
>>     
>
>