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.
