On Mon, May 31, 2004 at 01:48:21PM -0700, Greg Connor wrote:
| >
| >| Now, let's say what I *really* want is to return "unknown" (neutral) for
| >| Comcast,
| >
| >doesn't this do it?
| >
| > v=spf1 +a +ptr ?include:comcast.net include:earthlink.net -all
|
| Yes, you are right; I wasn't thinking of ?include as an option. This does
| what I want unless Comcast has an error in their stuff, or removes their
| record.
|
| >do you really want a ? from the include to cause a match on
| >include:comcast.net?
|
| Nope, probably not... but there are cases where I might want a ? from the
| include to continue on in my first record.
If the include:comcast.net returns an explicit neutral ("?")
value, there's no match, and you do continue.
Only if it returns an unknown/error exception do you get an abort.
|
| error=break
| Stop processing the current record, but if the error was in an include,
| continue with the previous record after the include: This allows a crude
| type of nesting. (In other words, if there is an error with the include
| record, come back here. This could include unsupported mechanisms.)
|
| unknown=break
| If the included record results in unknown, don't return it, instead
| continue with the previous record. (In other words, if the include record
| can't say pass for sure, come back here)
|
These basically mean we want to change the failure modes.
Presently, if we encounter a processing failure, we abort.
If the failure is temporary, we abort tempfail.
If the failure is permanent, we abort permfail.
The question is what a permfail should do.
We can fail open, as we presently do; the semantic becomes
equivalent to neutral.
We can fail closed, which run the risk of false positives by
clients that don't understand new mechanisms, even if those
new mechanisms are widely accepted.