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 >> > >