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?) 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. Luckily, I'm running SA from qpsmtpd, which should only run it once when it receives the double delivery. I suppose SA could prevent this issue from happening in other cases by storing the message-id together with the spent token. 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 In any case, I've configured it now and it still doesn't work. Off again working on debugging it. Christian.
