Re: Hashcash not working
On 31 Jul 2015, at 13:23, Christian Jaeger wrote: On July 31, 2015 4:51:02 PM CEST, Bill Cole sausers-20150...@billmail.scconsult.com wrote: John Levine wrote a definitive debunking of e-postage schemes including hashcash over a decade ago (http://www.taugh.com/epostage.pdf) and published an update (substantively unchanged) via Virus Bulletin in 2009 (https://www.virusbtn.com/spambulletin/archive/2009/03/sb200903-epostage.dkb?mobile_on=no). All of his points against e-postage in general and hashcash specifically have held up over time. I've read both links, they both bring the same two arguments: And more, so maybe you missed the fact that the topic of whole piece in both versions was e-postage in general -- of which hashcash is just one specific variety -- and that most of the general problems with e-postage apply to hashcash (and are not primarily technical.) The technical problems are that some computers are a lot faster than others I see a social problem with this: that in principle it penalizes poor people. More precisely: senders with lower allocation of computing resources per mail recipient they wish to contact... This is the particular hashcash case of a general e-postage problem. If todays mail sewers like MS, Google, Yahoo, GMX lived in a hashcash-heavy world, their users would notice more how they get a service worth at most what they pay for it. That is not a moral argument against whether hashcash *should* be widely adopted, it is a pragmatic point explaining one basic reason why it never will be. But let me restate: As I already said in my other email, for me hashcash seems to make sense where you really need to deliver a particular important, personal email. I don't care for a fairy dust solution that would solve sending legitimate mass email (be it mailing lists or ). I'm fine with those being filtered the way they are now. I'm caring to reduce the risk of loss of *important* emails, especially in situations where currently the risk is high, i.e. there's no whitelisting through previous communications. Those cases are few. [...] Evangelism for this e-postage use case started before hashcash was suggested as an alternative to micropayments. It has had many adherents trying to make it work. The key unstated premise behind it has become less true over time: that valuable non-spam email from a first-time or rare correspondent is likely to be blocked by spam filtering that examines message content. It may have seemed like a reasonable premise to some people in the mid-90s when spam filtering was embryonic and a lot of methodologies yielded high false positives. It's delusional today. Yes, that's when user's clients get the ability to compute hashcash, and ISPs adopt it. I.e. when it really catches on. Before that point, there's a phase where we're experimenting and hashcash doesn't play a big role in spam recognition (and grandma doesn't even come into play). The article argues in an absolute that ignores possible developments. Maybe 20 years of e-postage ideas and experiments, 17 specifically of hashcash is not enough time and there's still hope for them working. Maybe unicorns really exist too... and that currently spammers have a lot more computer power at their disposal than legitimate senders do Furthermore, spammers have vast arrays of hijacked `zombie' computers at their disposal. Blacklist maintainers report adding 10,000 newly hijacked computers to their blacklists per day. No legitimate mailer has anything like 10,000 computers dedicated to sending mail, much less 10,000 additional computers a day, meaning that it would be easier for spammers to satisfy hashcash than for legitimate senders. It compares a daily differential in the numbers of hijacked computers worldwide with the numbers of computers available to a single mailer? (How many are *removed* from the blacklists per day, btw?) It is my understanding that around the time that was written, the CBL was growing at a net rate of a few thousand per month. Based on my own current data from a very small server where I can do risky things to gather data, one fingerprintable botnet (Cutwail) that has been reported to be on the scale of 20k machines has a median member lifetime around 7 days. If I see a member I am almost sure to see the same member again later and about half keep showing up for a week. Some are active for many months. Please give me actual real numbers and I can do actual calculations. You really don't need a precise calculable set of numbers to understand the validity of this point. Spammers engage in mass theft of computing power to send spam, stealing orders of magnitude beyond the facilities available to any legitimate sender. In doing so they have the ability to put a constant inflationary pressure on a hashcash economy. If it ever becomes worthwhile to put hashcash on messages, spammers will have the upper hand
Re: Hashcash not working
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.
Re: Hashcash not working
nevermind, envelope recipient, but that's also easy and contained in the Received headers Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mail-gw.thelounge.net (THELOUNGE GATEWAY) with SMTP id 3mjWRW6GLQz1l for h.rei...@thelounge.net; Fri, 31 Jul 2015 16:37:43 +0200 (CEST) Am 31.07.2015 um 16:45 schrieb Reindl Harald: Am 31.07.2015 um 16:37 schrieb RW: 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 really? wonder how the SPF tests which need the envelope by defintion would work than? i guess because the heuristics mentioned below the same for FREEMAIL_ENVFROM_END_DIGIT HK_RANDOM_ENVFROM which all works out of the box https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html _ envelope_sender_header Name-Of-Header SpamAssassin will attempt to discover the address used in the 'MAIL FROM:' phase of the SMTP transaction that delivered this message, if this data has been made available by the SMTP server. This is used in the EnvelopeFrom pseudo-header, and for various rules such as SPF checking. By default, various MTAs will use different headers, such as the following: X-Envelope-From Envelope-Sender X-Sender Return-Path SpamAssassin will attempt to use these, if some heuristics (such as the header placement in the message, or the absence of fetchmail signatures) appear to indicate that they are safe to use. However, it may choose the wrong headers in some mailserver configurations. (More discussion of this can be found in bug 2142 and bug 4747 in the SpamAssassin BugZilla.) signature.asc Description: OpenPGP digital signature
Re: Hashcash not working
Am 31.07.2015 um 16:37 schrieb RW: 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 really? wonder how the SPF tests which need the envelope by defintion would work than? i guess because the heuristics mentioned below the same for FREEMAIL_ENVFROM_END_DIGIT HK_RANDOM_ENVFROM which all works out of the box https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.html _ envelope_sender_header Name-Of-Header SpamAssassin will attempt to discover the address used in the 'MAIL FROM:' phase of the SMTP transaction that delivered this message, if this data has been made available by the SMTP server. This is used in the EnvelopeFrom pseudo-header, and for various rules such as SPF checking. By default, various MTAs will use different headers, such as the following: X-Envelope-From Envelope-Sender X-Sender Return-Path SpamAssassin will attempt to use these, if some heuristics (such as the header placement in the message, or the absence of fetchmail signatures) appear to indicate that they are safe to use. However, it may choose the wrong headers in some mailserver configurations. (More discussion of this can be found in bug 2142 and bug 4747 in the SpamAssassin BugZilla.) signature.asc Description: OpenPGP digital signature
Re: Hashcash not working
On Fri, 31 Jul 2015 16:47:34 +0200 Reindl Harald wrote: nevermind, envelope recipient, but that's also easy and contained in the Received headers Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mail-gw.thelounge.net (THELOUNGE GATEWAY) with SMTP id 3mjWRW6GLQz1l for h.rei...@thelounge.net; Fri, 31 Jul 2015 16:37:43 +0200 (CEST) It's usually there, but some servers never add it. There are also some mail systems where all mail has a recipient header like Delivered-To, even if received for multiple recipients.
Re: Hashcash not working
On July 31, 2015 4:37:14 PM CEST, RW rwmailli...@googlemail.com wrote: 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. That's why I mentioned RECIPIENT. The MTA knows where it's going to, the information just needs to be passed on to SA. It's probably for the best that it doesn't work by default. It would likely have been exploited by spammers if it were. Well, it seems that right now hashcash is of no use. If we actually use it then the worst that could happen (in the case that spammers can really generate hashcash as easily as legitimate senders) is that it's also of no use. But isn't there also a chance that it's not turning out as bad? 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. I don't really see the logic in your statement. It doesn't need to be ubiquitous, my thinking is that it would be useful as an additional indication for *important* email that the email isn't spam (especially if end client applications (web or otherwise) would adopt it, so that it could use something like 20 seconds of CPU time). E.g. not for mailing list emails, but for personal email where you don't want the email to be lost (have a button that says retry more forcefully or something, that you could push when you suspect the receiver didn't get a mail, or when you're contacting someone the first time and think it's important, that then does the 20 second (or more) hashcash calculation). 20+ seconds would be rather hard to compete against I'd think. If it means that a spammer could only afford say 2 seconds, and even for the 2 seconds would have to reduce sending rate to a tenth, that would already be good? If it means that they can only make *some* of ther spam as well deliverable as currently, that's also success, no? I expec t the scores to adapt so that low-effort hashcash would have zero effect on the spam score, but high-effort hashcash would still point towards ham. I think it boils down to the question of whether spammers really have enough CPU power for multi-second hashcash per recipient calculations (or, as much as legitimate senders). Others have argued that the heat/fan activity would make some people more suspicious and make them get rid of the abuser. (This by itself would already be a good thing.) I also wonder whether it wouldn't be more worthwhile for criminals to use the available CPU power for Bitcoin mining instead? Any sources for numbers? Why not simply try it? Wouldn't the worst case be that the scores would be adapted to around zero when spammers would really start using it? Is it fear of making the system more complex and then not understanding it anymore? (BTW is there a framework in SA to statistically analyze combinations of characteristics? So that by learning (sa-learn) client installations could adapt automatically? Or is that too CPU heavy? Or precalculate the data for everyone but let client installations adapt those (implicit) 'scores' through learning?) Christian.
Re: Hashcash not working
On 31 Jul 2015, at 7:36, 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. As it should be. There is no default value that could be reasonable for a broad range of sites and users for the commonplace neglect times of SA installations. One of the features of hashcash that raises it a millimeter above most other species of the naive conceptual genus of e-postage is the ability of receivers to arbitrarily set their own price AND to raise the price over time to compensate for Moore's Law and botnet growth. If you are not prepared to actively manage a hashcash deployment, it is not going to be useful and over time will reduce your SA accuracy in the unlikely event that hashcash becomes popular enough for spammers to notice. John Levine wrote a definitive debunking of e-postage schemes including hashcash over a decade ago (http://www.taugh.com/epostage.pdf) and published an update (substantively unchanged) via Virus Bulletin in 2009 (https://www.virusbtn.com/spambulletin/archive/2009/03/sb200903-epostage.dkb?mobile_on=no). All of his points against e-postage in general and hashcash specifically have held up over time.
Re: Hashcash not working
On July 31, 2015 4:51:02 PM CEST, Bill Cole sausers-20150...@billmail.scconsult.com wrote: John Levine wrote a definitive debunking of e-postage schemes including hashcash over a decade ago (http://www.taugh.com/epostage.pdf) and published an update (substantively unchanged) via Virus Bulletin in 2009 (https://www.virusbtn.com/spambulletin/archive/2009/03/sb200903-epostage.dkb?mobile_on=no). All of his points against e-postage in general and hashcash specifically have held up over time. I've read both links, they both bring the same two arguments: The technical problems are that some computers are a lot faster than others I see a social problem with this: that in principle it penalizes poor people. But let me restate: As I already said in my other email, for me hashcash seems to make sense where you really need to deliver a particular important, personal email. I don't care for a fairy dust solution that would solve sending legitimate mass email (be it mailing lists or ). I'm fine with those being filtered the way they are now. I'm caring to reduce the risk of loss of *important* emails, especially in situations where currently the risk is high, i.e. there's no whitelisting through previous communications. Those cases are few. It's easy to spend even minutes of CPU time on such cases. Or, since the article argues that grandma has a 100 Mhz computer, the ISPs could offer premium email, where the piece costs a few cents (hey, cheaper than SMS with many providers!), and then run hashcash on a few powerful servers in parallel for a minute with a total CPU budget of several minutes. Now I would expect that ISPs in 3rd world countries would offer hashcash generation for a lower margin, and hence even people there could easily afford sending important mails with hashcash. (If grandma's ISP wouldn't offer premium email, she'd have to send the email without hashcash, and it would still have a decent chance of deliverability, or she would have to let her computer up for an hour until it is sent. As I said, it would be rare to need it.) Yes, that's when user's clients get the ability to compute hashcash, and ISPs adopt it. I.e. when it really catches on. Before that point, there's a phase where we're experimenting and hashcash doesn't play a big role in spam recognition (and grandma doesn't even come into play). The article argues in an absolute that ignores possible developments. and that currently spammers have a lot more computer power at their disposal than legitimate senders do Furthermore, spammers have vast arrays of hijacked `zombie' computers at their disposal. Blacklist maintainers report adding 10,000 newly hijacked computers to their blacklists per day. No legitimate mailer has anything like 10,000 computers dedicated to sending mail, much less 10,000 additional computers a day, meaning that it would be easier for spammers to satisfy hashcash than for legitimate senders. It compares a daily differential in the numbers of hijacked computers worldwide with the numbers of computers available to a single mailer? (How many are *removed* from the blacklists per day, btw?) Please give me actual real numbers and I can do actual calculations. So where's the actual debunking? Christian.
Re: Hashcash not working
On 31 Jul 2015 17:57:28 +0200 Christian Jaeger wrote: On July 31, 2015 4:37:14 PM CEST, RW rwmailli...@googlemail.com wrote: 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. That's why I mentioned RECIPIENT. The MTA knows where it's going to, the information just needs to be passed on to SA. You're making some assumptions about how SA is being used. I can see why they went with hashcash_accept, it always works - even if the recipient is rewritten. 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. I don't really see the logic in your statement. It doesn't need to be ubiquitous, In the hashcash FAQ they argue that hashcash is useful against botnets because it slows them down. But this would only be correct if hashcash were essential to delivery. If it isn't then hashcash support in spamfilters would benefit spammers because they can send a mixture of spam with and without the header. They'd get extra deliverability without any slow down at all. I think it boils down to the question of whether spammers really have enough CPU power for multi-second hashcash per recipient calculations (or, as much as legitimate senders). One of the problems with hashcash is that its algorithm is well optimised for GPUs and other heavily parallel hardware. The 20 seconds on an ordinary core could be milliseconds on a machine made from just gaming hardware. Spammers also have the advantage that they don't have to work in real time - they can generate postdated stamps in advance of a spam run.
Re: Hashcash not working
On July 31, 2015 9:13:03 PM CEST, RW rwmailli...@googlemail.com wrote: On 31 Jul 2015 17:57:28 +0200 Christian Jaeger wrote: On July 31, 2015 4:37:14 PM CEST, RW rwmailli...@googlemail.com wrote: 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. That's why I mentioned RECIPIENT. The MTA knows where it's going to, the information just needs to be passed on to SA. You're making some assumptions about how SA is being used. When does RECIPIENT break? man qmail-command says that RECIPIENT is the envelope recipient address. Shouldn't this be the unchanged To/Cc/BCC address that the mail is currently being delivered to, assuming no forwarding was done? I can see why they went with hashcash_accept, it always works - even if the recipient is rewritten. I don't expect hashcash in forwarded email to be found without special configuration. If it finds the matching hashcash in non-forwarded configuration that sounds fine to me. I don't really see the logic in your statement. It doesn't need to be ubiquitous, In the hashcash FAQ they argue that hashcash is useful against botnets because it slows them down. But this would only be correct if hashcash were essential to delivery. If it isn't then hashcash support in spamfilters would benefit spammers because they can send a mixture of spam with and without the header. They'd get extra deliverability without any slow down at all. Hm, I see your point, they could use the CPU they have available but still saturate their network capability, too. The effect will be complicate to calculate. Possibly by sending spams without hashcash over the same network their IPs will be blacklisted enough to prevent the spam with hashcash from being delivered either. I guess their strategy will be to pregenerate as much hashcash as they can, then first send spam with hashcash, then when they've run out of hashcash send spam without, thus staying more likely in the green while they have hashcash then continue as long as they can or makes sense without. (I don't have deep insights into how spammers work, I'm just reckoning here. Hopefully at least as well as the writers of some articles.) One of the problems with hashcash is that its algorithm is well optimised for GPUs and other heavily parallel hardware. The 20 seconds on an ordinary core could be milliseconds on a machine made from just gaming hardware. Normal CPUs have SIMD instructions, and one could use all cores, then the difference shouldn't be that vast (make that number of milliseconds something in the range of thousands, then?). But agreed, scrypt would make more sense here. This is an attack on the hashing algorithm, not the concept as a whole. (Calculating hashes in browsers will eagerly await widespread support of SIMD in JavaScript; but this is again a problem that could go away if hashcash really got successful, browsers could include hashing functions implemented in C/C++/Rust/ASM.) Spammers also have the advantage that they don't have to work in real time - they can generate postdated stamps in advance of a spam run. Ok, that means they can keep their moves quick (quick bursts until IP blocked etc.), but the total amount of hashcash they can produce stays the same. (Also see the above.) Maybe the concept could be extended to use a challenge-response scheme (e.g. where the receiving SMTPd would present a challenge, then let the sender (optionally) disconnect, calculate the hashcash with the challenge as additional input, then reconnect; or provide the challenge over DNS with short TTL). Is there a(nother) good place already to discuss these concepts? (Wiki, etc.) I don't intend to 'spam' this list too much with this. But I think it's interesting to read and think more about this. (There seems to be a ML linked from hashcash.org, but the last message in the archives is from 2012.) Christian.
Re: Hashcash not working
Christian Jaeger wrote: On July 31, 2015 9:13:03 PM CEST, RW rwmailli...@googlemail.com wrote: On 31 Jul 2015 17:57:28 +0200 Christian Jaeger wrote: On July 31, 2015 4:37:14 PM CEST, RW rwmailli...@googlemail.com wrote: 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. That's why I mentioned RECIPIENT. The MTA knows where it's going to, the information just needs to be passed on to SA. You're making some assumptions about how SA is being used. When does RECIPIENT break? man qmail-command says that RECIPIENT is the envelope recipient address. Shouldn't this be the unchanged To/Cc/BCC address that the mail is currently being delivered to, assuming no forwarding was done? First of all, not everyone uses qmail. Exim and Postfix can call SA directly in certain configurations. Exim, Postfix, and sendmail can all use Mailscanner or Amavis IIRC. Postfix and sendmail can use milters like MIMEDefang or spamass-milter. Most of these configurations plug SA into the mail system at a point where one message may have many recipients who may have different filter policies as expressed in the SpamAssassin configuration. There *is* no The recipient. -kgd
Re: Hashcash not working
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.
Re: Hashcash not working
On Fri, 31 Jul 2015, RW wrote: On Fri, 31 Jul 2015 16:47:34 +0200 Reindl Harald wrote: nevermind, envelope recipient, but that's also easy and contained in the Received headers Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mail-gw.thelounge.net (THELOUNGE GATEWAY) with SMTP id 3mjWRW6GLQz1l for h.rei...@thelounge.net; Fri, 31 Jul 2015 16:37:43 +0200 (CEST) It's usually there, but some servers never add it. There are also some mail systems where all mail has a recipient header like Delivered-To, even if received for multiple recipients. The embedding of the envelope recipient in Received headers is MTA configuration dependent and even those that do will usually omit it when there's more than one envelope recipient for a message. The Delivered-To header and its ilk (EG: Return-Path) are usually only added at the final delivery MTA point and may not be visible at an intermediate point. It's best if the mail-system glue used explicity makes envelope sender and recipient available to SA via reliable mechanism. For example if using a milter, make it add synthesized X-Envelope-From X-Envelope-To headers to the stream it passes to SA. -- Dave Funk University of Iowa dbfunk (at) engineering.uiowa.eduCollege of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include std_disclaimer.h Better is not better, 'standard' is better. B{
Hashcash not working
Hi I've implemented (or at least so I thought) Hashcash for my outgoing mail (in a Perl wrapper around qmail-remote that I already had to do DKIM), using the `hashcash` tool as provided by Debian, using the `-X` command-line option. This tool returns multi-line headers if the email address the hash-cash is minted for is long enough. This might be the reason that Mail-SpamAssassin-3.4.1 ignores those, I guessed, so I delved into the code. Here's an example header it generates (you could also check the source of this email): X-Hashcash: 1:23:150729:c...@a.christianjaeger.ch::BIsU5nVO5XGrvOIr:00 6t75 Now another thing I notice is that this format is longer than the examples shown in the code, e.g. X-hashcash: 1:20:040803:a...@cypherspace.org::a1cbc54bf0182ea8:5d6a0 Anyone knows if that is already a problem? Then I noticed that the following regex disallows \n in the header value; do decoded header values have a \n where they wrap, or not? Then I notice in this commit: https://github.com/apache/spamassassin/commit/a95d2cfd2cc07deac9842cfaf10d6d9a85365b12 # untaint the string for paranoia, making sure not to allow \n \0 \' \ - $hc =~ /^([-A-Za-z0-9\xA0-\xFF:_\/\%\@\.\,\= \*\+\;]+)$/; $hc = $1; + if ($hc =~ /^[-A-Za-z0-9\xA0-\xFF:_\/\%\@\.\,\= \*\+\;]+$/) { +$hc = Mail::SpamAssassin::Util::untaint_var($hc); + } if (!$hc) { return 0; } This looks like it isn't correct: before the patch, it would assign undef to $hc if the regex fails (right?), now it leaves the tainted original $hc value in place. Surely not what was meant, right? I'm planning to debug this further (hm, debugging a live daemon is always painful, actually writing a tool for that now, will defer my work here), but would welcome feedback. Christian.
Re: Hashcash not working
On 29 Jul 2015 20:55:55 +0200 Christian Jaeger wrote: Hi I've implemented (or at least so I thought) Hashcash for my outgoing mail (in a Perl wrapper around qmail-remote that I already had to do DKIM), using the `hashcash` tool as provided by Debian, using the `-X` command-line option. This tool returns multi-line headers if the email address the hash-cash is minted for is long enough. This might be the reason that Mail-SpamAssassin-3.4.1 ignores those, I guessed, so I delved into the code. Here's an example header it generates (you could also check the source of this email): X-Hashcash: 1:23:150729:c...@a.christianjaeger.ch::BIsU5nVO5XGrvOIr:00 6t75 This eventually worked for me, when I set-up hashcash correctly. The plugin is on by default and use_hashcash defaults to 1, but you need to set hashcash_accept to an appropriate value to allow c...@a.christianjaeger.ch.