https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6490
--- Comment #37 from [email protected] 2011-05-11 17:44:39 UTC --- As the author: I am satisfied with the code which was committed. There are no existing rules which are affected by this change. Furthermore, because it is debatable whether an unauthenticated sender should be penalized, I suggested a "SPF_NONE" rule in the OP with a zero score. This need not actually be added to the formal ruleset for that reason. Some may feel that "unauthenicated" should mean possessing NO sender authentication at all, and therefore, an SPF "none" result should be matrixed with similar "none" results from DKIM and PGP (of which we do have other modules to check for such signatures) before penalizing (if at all) the message for using nothing to verify its sender. This is why I decided on proposing only the infrastructure patch to the code. I expect that those who will use the the information of this additional result state will do so in their local configuration files. I use a rule with a score of 2.0 (and a threshold of 7.5, not the default 5.0). However, I also check for SPF in the MTA at "mail from" so my implementation will never pass to SA a message which SPF hardfails or errs, but all other results (pass, none, neutral, softfail, and policy [RFC 5451]) do get passed. (I generate a policy result when I have a pre-registered, authenticated forwarding MTA delivering a message. I don't rely on a forwarder implementing SRS, etc....) Internally, I note that a "policy" result is treated the same as the error results - no state is set. That is intentional as it means that the true SPF state was overridden for some reason (usually forwarding). As for new rules, I suggest that if anything is added at this time, it be added as COMMENTS so as to alert the SA user population that the ability to act on SPF=none exists but that no active rule is being implemented at this time (as opposed to a proposal of adding a rule with a score of 0.1 or other trivial amount). An actual score for a global distribution of the rule may be determined at a later date by testing to see how often it fires. This rule is likely to fire on "ham" as well as spam as it is an indicator of an orthogonal property which is often seen with spam; not spammy by itself. Testing on the rule is needed before setting a non-zero score. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
