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
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
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
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
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.