https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5684
--- Comment #20 from [email protected] 2010-11-16 19:54:30 UTC --- Actually, no. I let the following SPF results into SA for scoring: pass, neutral, softfail, and none; the latter three results receiving non-zero scores. Failures, errors, or passing SPF records based on "+all" or wide CIDR masks ("/0" ... "/7") are taken care of during the SMTP "MAIL FROM" state (via my MIMEDefang filter routine), thus never reaching SA to be scored. SPF "pass" receives a negative SA score? Interesting, but misguided. If per SPF, I know that a message is forged and therefore will be rejected, why should I continue to process it? I save computational power and bandwidth by making a decision as soon as possible to terminate the SMTP transaction with an error. All the information for an SPF result is available at "MAIL FROM:", so why should I consider anything that changes the result at any later step? With your patch, you could be scoring a "+all" when SPF returns failure or other states if such strange SPF strings direct such an outcome. Does that make sense? Should "+all" be a factor when another mechanism produces the result? I say no - and that's why I look for "+all" (or a wide CIDR match) only when the SPF result is pass - because that is the result beneficial to spammers and their trickery. Not all forged messages need be spam. Practical jokes and revenge messages (usually by former lovers or other close relationships) are good examples of non-spammy forgeries. SPF is an anti-forgery solution, not an anti-spam one. Granted that much spam is also forged, thus yielding a good reason for SA inclusion, I note that about half of the people writing about SPF mischaracterize it. Also, your "+all" check in SPF will undoubtedly be used as an override to the SPF "pass" result with a positive SA score so as to cause message rejection, so why defer that to the SMTP message eom state when such information is available earlier? You are correct that I consider the forged state as binary in nature. Why shouldn't it be? The characteristic itself is binary, with basically a tri-state result set: Yes (2 results), no (1 result), or undetermined (4 results, including errors). Since you asked -- I consider these operations as: FCrDNS: Binary. I reject failures before the "HELO" state. DNSBLs: I consider 4 of them as binary and reject immediately. I score the rest because they have some false positives and are thus not as reliable. I don't disagree with the overall intent of your patch. I clearly disagree with the implementation of that intent. I also note that your solution may cause the score to be altered when "+all" is present but UNUSED in determining the SPF result and call that inappropriate to the "corrective measure" of adding this functionality in this manner. My solution may be a bit more strict, but it also generates a proper RFC 5451 answer (the "Authentication-Results:" header), and only penalizes those SPF results where "+all" is the determining mechanism, plus the bonus of it's not fooled by CIDR equivalents. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
