Nelson Serafica wrote: > I want to enable spf. AFAIK, it was enabled by default. However, I > want to change the score. Instead of -0.001, I want it to change to > -2. So I edit local.cf <http://local.cf> and put: > > header SPF_PASS eval:check_for_spf_pass() > describe SPF_PASS SPF: sender matches SPF record > score SPF_PASS -2 > > Then I update rules by doing spamassassin -D --lint. The debug says > there are 1 issues detected. When I check the output of the debug, it > says: > > [1217] warn: rules: failed to run SPF_PASS test, skipping: > [1217] warn: (Can't locate object method "check_for_spf_pass" via > package "Mail::SpamAssassin::PerMsgStatus" at (eval 1248) line 1288. > [1217] warn: ) > > I have 25_spf.cf <http://25_spf.cf> in my spamassassin default rules > directory. Does this mean that spf is not really enabled at all? > Please advise how to enable it if not and what is the proper way to > change the score if my way is not correct. > > I tried to check Mail::SpamAssassin::PerMsgStatus in > http://search.cpan.org and it point me to > Mail-SpamAssassin-3.2.5.tar.gz. However, I'm already using > SpamAssassin Server version 3.2.5
First, to change a rule score, all you need is a score statement. You do not need to re-declare the entire rule from scratch, and you're just wasting space in your local.cf. Also, if the rule is ever upgraded by sa-update, the copy in local.cf will over-ride it, and downgrade the rule. Second, it looks like SPF is not enabled on your system, otherwise the eval would not have errored. Check your .pre files and make sure the loadplugin statement for SPF is not commented out, and make sure you have the appropriate supporting SPF libraries installed. Third, I would *strongly* discourage assigning a significant score to SPF_PASS. I strongly support SPF, but people really need to understand its limitations when using it. Passing SPF is not a reliable indicator of nonspam. All it does is verify the sending server was authorized by the controller of the domain used in the envelope FROM. However, if a spammer controls the domain, he will obviously approve his own spam sending servers. SPF is completely self-certified, with no external authorities, so SPF is only as trustworthy as the domain it is included in. SPF by itself is only useful in the negative. Failure indicates forgery. Passing SPF indicates nothing, unless you also trust the domain owner, but that's a per-domain thing. All you can verify from passing SPF is that the sending server matches the claims of the domain owner.. but who is that, and why do you trust them? Now, if you have a particular domain in mind, things like whitelist_from_spf work well, but that's only effective because you trust the domain owner to not be a spammer. Many people confuse passing SPF with being a general-purpose whitelist criteria. It is not designed for this use, and won't work when used this way. Many of the more misguided arguments against SPF boil down to folks who expect that it needs to work as a white tool, and realize it won't work that way. SPF is a forgery detection technology, which has some uses in spam detection, but it's use as a whitelist has notable limitations.
