Nico Kadel-Garcia wrote:
[...] SPF is not an *approval* method, it's a *rejection* method. Any
other filtering the recipients are doing can certainly still be done.
I do not agree completely. Although the SPF specification talks about
what receivers should do depending on the various SPF result codes, I
still think SPF is neither a "rejection method" nor a "approval method",
but an "authentication method".
Essentially, SPF doesn't (or shouldn't) make statements about whether a
message should be accepted or rejected, but just about whether a sender
address is authentic according to a domain owner's published policy. Just
because it is so very obvious to reject messages with unauthentic sender
addresses, that doesn't mean such a reaction _must_ be taken.
Alex van den Bogaerdt wrote:
You can advertise your policy but you cannot make the receiver do what
your want.
Of course not. The question is what the policy means. "v=spf1 -all", for
instance, does _not_ mean that all mail from the domain in question should
be rejected. It means (and you should assume that it means) that all mail
claiming to come from that domain is illegitimately using that domain in
the sender address. It is up to the receiver what to do with such mail.
At the moment there are plenty of domains experimenting with SPF. Some
of those _are_not_ sure, yet they do publish -all.
I think that is good enough reason not to reject. [...]
Although your conclusion is correct, it is for all the wrong reasons. As
I said above, SPF policy never implies that mail should be rejected, but
only that certain mail has unauthentic sender information.
Still, if domain owners _do_ publish a "-all" policy, this must be
respected by the receiver in all cases in order to make SPF work. Even if
the receiver generally decides not to reject unauthentic mail, he must
treat mail failing the SPF check as unauthentic mail. Period.
If publishers publish "-all" without knowing about the consequences, this
is what needs to be changed, not any standards-conforming receiver-side
methodology.
On an unrelated matter touched by Alex van den Bogaerdt:
Alex van den Bogaerdt wrote:
And I'm not entirely sure about the status of looking up the zone cut.
Most likely there are plenty of clients that do not look at subdomains.
[...]
[...] unless the zone-cut, tree-walking or whatever it is called makes
it into the spec. I do think it should be there, eventually, but I
doubt it is in right now.
The zone cut default algorithm is in the current official specification
draft, draft-schlitt-spf-classic-00[1], but the council has recently
decided to remove it from future versions of the specification[2] due to
its significant technical problems.
References:
1.
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-00.txt
2. http://spf.mehnle.net/Council_Resolution/21