SA3 claims to support SPF. SPF is fundamentally broken. Please make sure SPF checking is disabled when we ship SA3.
SPF points, in the *non*spam direction, are either going to be 0 or -0.001. so all SPF will be able to do by default in SA3 will be to mark more messages as spam, not the other way around; there's no hole there for the spammers to exploit, just another way for us to spot the spammers ;)
That's precisely the wrong way round. To the extent that SPF conveys any useful information at all, it's useful only for whitelisting -- i.e. for negative scoring, rather than positive scores. (With the exception of domains which never send _any_ mail and have just a '-all' record). If a mail comes from an IP address which is really associated with that domain, you have a reasonable expectation that it's not a forgery. So you can give negative points, or avoid doing sender-verification callouts to check the address in question is real and will receive bounces. On the other hand, if a mail comes from a _different_ IP address, you know nothing. It _could_ be a forgery, or it could be a mail which did originate from a valid user at that domain, and was sent via a local ISP while elsewhere, or was sent to someone with a .forward file, or any other of a number of reasons why a valid mail would come from other IP addresses. The SPF proponents have plans to change the way the whole world works and change all those reasons why valid mail for a given domain can in fact come from anywhere -- but until their ideas are finalised, and then _implemented_ ubiquitously, SPF remains a fundamentally broken concept. The problem is that naïve mail users and admins don't realise just how broken SPF is, and will be more likely to use it if we endorse it be shipping software which uses it. We should not ship software configured to use SPF at all -- just as we shouldn't ship software configured to use some of the less reputable DNS blacklists. By doing so we would contribute, albeit indirectly, to the breakage which SPF causes.
If, as David said, SPF is fundamentally broken for its "intended" use in whitelisting, then why should that be the only way it is used? SpamAssassin is not written to make ideological statements, it is a spam filter. If the information it gathers from SPF records can be used to identify some spam, then it is useful. If a spammer tries to forge a From address of a domain when that domain uses SPF records and does not allow mail to be sent through servers not listed in the SPF records, then it is possible to use the SPF failure to block that mail. SpamAssassin 3.0 will not use SPF in a way that gives spammers a loophole through the filters. If SPF really is "fundamentally broken" then SpamAssassin will never make use of it in the way that the designers of SPF intend. "Naive mail users and admins" will not look at SpamAssassin and decide that they should support the political process of promoting SPF. If they are so naive they will just run what SpamAssassin provides and not care how it catches the spam. There is no need to disable SPF processing in SpamAssassin 3.0 any more than it already is being disabled by having SPF_PASS be treated as a meta rule or forced to score -0.001 so that it can tested for without providing any loophole for spammers.
sounds like this is an argument that should take place upstream and not in RH bugzilla. please resolve with spamassassin team. if SPF is so broken, then I'm sure they will listen to reasonable discussions around it, but I imagine they will listen more closely if it takes place on their mailing lists.
Plus, as I understand it, this is moot, because SPF *is* "disabled" in Fedora -- for it to work, it needs the Mail::SPF::Query module, and we don't include that.