SPF has left itself open to this criticism by not having a clear
policy on forwarding. Forwarders will ask 1) How do I know which
name to authenticate? and 2) How do I pass the result downstream?
There needs to be a simple, widely accepted answer to these questions
or SPF will fail.
I was hoping we wouldn't be discussing this aspect of SPF quite yet.
I believe we should first fix the DNS related problems (load,
uncacheable macros, etc). Without these, forwarding policy does not
matter, because the IETF will not allow a DNS-heavy SPF draft to become
a standard.
In that context, an unfocussed approach to fixing problems might just be
a waste of time, if a standard is not possible.
So I think we should put this one on the back burner, and come back to
it after the -01 draft (which must include DNS fixes) is published. In
this way, any DNS fixes can be readjusted (instead of introduced for the
first time) at -02, along with the added forwarding policy.
That said, when the time comes, I will propose a way to publish the
local policy.
What any secondary MX or forwarder wants to know is... "If I accept this
piece for the recipient, will they accept it from me?"
For secondary MX's this is a real problem, because currently all spam
goes through there. The secondary MX cannot really do any kind of spam
filtering for the primary MX.
So my proposal will involve a *modifier* which can be checked by the
secondary MX, and it will tell it what the primary MX would do. (ie,
would it reject fails? Would it reject anything else? Would it accept
"none" or "neutral" or even "pass" if it came through a secondary MX?
Would it accept mail from the secondary if the sender is not already
whitelisted? Will the primary MX reject the mail because the receipient
was faked and does not exist?)
The proposal will be along the lines of the l= modifier, which lists
some rejection rules for secondary MX's or forwarders, along with a
place to look for another SPF record that would be used as the "local
policy" to use when mail is to be forwarded.
Anyway, I have some ideas that I think are backwards compatible with SPF
-01, but I don't think it's the right time to spend time on them now.
They are very important additions, but it'd be best to introduced them
in a planned manner.
Regards,
Radu.