https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5684
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |software+spamassas...@kd6lv | |w.ampr.org --- Comment #15 from [email protected] 2010-11-15 16:27:59 UTC --- I am of the opinion that this is a poor approach. The condition should not be whether the SPF record contains a "+all" but that such a mechanism is the reason why a "pass" result is generated. Consider: "v=spf1 a mx all". Clearly, if the "a" or "mx" mechanism is the reason for the passing result, there is nothing "funny" going on here, despite having a "+all" in the record. Also, SPF is better done at the SMTP "MAIL FROM" state, not the "DATA"/eom state where the message has already been transferred. SPF failures should be rejected earlier in SMTP. However, SPF "none"* vs. "neutral" vs. "softfail" are still results for SA scoring. (* - see bug 6490 for "none" being available to SA.) RE - Comment #7: I agree, and I also disallow by policy any passing result that came from a CIDR'ed mechanism where the mask is less than 8. I chose "/8" because: 1) It is the largest allocation to any single organization, and 2) it divides the IPv4 address space into 256 blocks - and for a spammer to cover enough of it to be worthwhile, he would violate SPF's mechanism limit and/or the DNS size limit on SPF or TXT RRs, even with nested included SPF records. I call SA from MIMEDefang, so I perform my primary SPF check in MD's hook filter_sender() routine. When it calls Mail::SPF, one of the returned fields is an explanation of the result. When pass results, the explanation is usually "Mechanism '*' matches", and I parse the "*" for a CIDR or "all". Such "wide" CIDR-matching pass results are changed to the "policy" result per RFC 5451. Such action makes this patch completely unnecessary, plus it targets the wrong criterion. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
