In <20050503124601(_dot_)027C71799C(_at_)rune(_dot_)listbox(_dot_)com> Scott
Kitterman <spf2(_at_)kitterman(_dot_)com> writes:
If the risk is limited to a hole in the macro responses, how about treating
a macro error as the macro mechanism not matching rather than PermError.
Then the parser will trundle on to the end of the record and act
accordingly (-all, ?all, etc.).
William once enquired about how to construct an SPF record that needed
satisfy multiple conditions. I came up with the following solution:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200410/0961.html
That post gives an example of where a highly restricted SPF record
ends in +all and ignoring either of the includes would be A Bad
Thing.
The current spec would cause domains that use include: to be at risk. Who
knows, maybe my ISP adds some new servers and changes their SPF record to
add a couple of a: mechanisms and now my record is over the processing
limits (even though their record is legal and I didn't change anything).
Now my mail gets rejected even if it's not sent through that ISP.
I think include: mechanisms are risky, as are ptr: (and %{p})
mechanisms. You can't depend on others and not have a certain amount
of risk. Having PermError act the same as None has a different risk:
that your sender policy may be ignored because the ISP changed things.
-wayne