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.
