Re: SpamAssassin / hashcash deployment stats?

Wouldn't spamassassin benefit from knowing the recipients address
independently from hashcash requirement to know that?

At least when people write .procmailrc files to weed out spam a common
strategy is to throw away mail that is not To, or Cc one of your own
addresses.  If you know who the recipient is spamassassin could
negatively score based on absense of one of your own addresses.


Isn't there some kind of workable default that is unlikely to hurt?
Like *@`hostname` but explicitly excluding "localhost" as an allowed
hostname in a site wide config.  And $USER@`hostname` in an end-user
config?

I imagine the deployment of hashcash within SA could improve a *lot*
if we could find some workable default config.  People make the
minimal required settings in config files and I presume SA suffers
from this principle also.

Also Torsten writes:
> Why is it so dangerous to accepts stamps for all addresses?

Well if everyone accepts stamps for any address, a spammer can create
one stamp and re-use it for all recipients removing the cost that
hashcash tries to impose on senders.

Unfortunately spammers are faster "innovators" or early adopters than
busy mail admins...  We've already seen some fake hashcash headers
attached to spam (no work put into it, invalid stamp, but correct
syntax).

Adam

On Fri, Nov 04, 2005 at 08:13:20AM -0500, Eric S. Johansson wrote:
> Justin Mason wrote:
> >Yep, that's the case.
> >
> >Also worth noting that most users will not have it set up by default;
> >it requires a line of configuration (to tell it what stamp addresses 
> >you expect to receive stamps for).
> 
> pity, another opportunity lost.  there is no harm in turning the filter 
> on.  You just need to make the baseline value high enough for stamp to 
> activate its rule.  in other words, if the stamp value is below a 
> minimum setting, it has no effect and will prevent spammers from using 
> trivial stamp sizes to game spamassassin.
> 
> --- eric