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.
