On Fri, 31 Jul 2015 13:36:21 +0200 Christian Jaeger wrote: > On July 30, 2015 2:40:35 AM CEST, RW <rwmailli...@googlemail.com> > wrote: > > The plugin is on by default and use_hashcash defaults to 1, but you > > need to set hashcash_accept to an appropriate value > > That's disappointing. For me that barely counts as "on by default". I > was thinking that implementing hashcash would help get my mail > delivered to at least the spamassassin users, but this means that no, > only to the subset that cares about configuring it. > > Does SA not know which address(es) an email is being delivered to? If > it knows (knew), it could just compare those addresses, no? (E.g. > qmail sets various environment variables, e.g. RECIPIENT, when > running filters, can't SA use this? I'm using QPSMTPD, I suppose > spamc could be modified to pass recipients, too?) SA usually gets envelope information from headers. Since there are several headers that could contain the envelope recipient, it would need to be configured, so still wouldn't work by default.
It's probably for the best that it doesn't work by default. It would likely have been exploited by spammers if it were. > If the answer is no, then I realize that there's also an accidental > double-spend issue? My qmail-remote wrapper adds a X-Hashcash header > for every receipt address the qmail-remote is being called with. I > was thinking that the receiver could restrict itself to only look > (and mark in the database) the header for the delivery that's being > made. Now I worry that if I send an email with "To: f...@bar.com, > b...@bar.com" with two X-Hashcash headers that, if SA is run > separately for each sub-delivery, then it will mark both headers in > the first delivery and add a penalty for used hashcash to the second. From the quick look I had at the code, I think it only cancels one on each scan - it wouldn't matter which. The more significant problem is that for unix users and virtual home directories it creates per user databases by default. You can opt for a single database path, but it's still a Berkeley database file with all the problems that implies. > My decision to spend time to implement this was based on reading in > wikipedia[1] that SA "is checking them". I think this needs a mention > that it only happens when configured. If you don't disagree, I'll > change that. > > [1] https://en.wikipedia.org/wiki/Hashcash Hashcash for email isn't a very good idea. Even if it were ubiquitous and email couldn't be sent without it, it wouldn't be a major impediment to spammers. If spammers don't have to add a hashcash header to everything, it doesn't even slow them down, it's just an opportunity to make some of their spam more deliverable.
