...... Original Message .......
On Tue, 03 May 2005 15:12:29 -0500 wayne <wayne(_at_)schlitt(_dot_)net> wrote:
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
That's true, but this risk of my mail not being delivered because of SPF is
a lot more concerning than the risk of not getting the anti-forgery benifit
of SPF.
"Oh, you're new to SPF and you aren't sure you entirely understand it?
Well make sure your record has correct syntax and doesn't exceed any
processing limits before you publish because if you get it wrong, your mail
will get rejected."
I think that will be a hard sell on spf-help.
Scott Kitterman