On Mon, May 31, 2004 at 05:02:41PM -0400, Meng Weng Wong wrote:
| If you continue, you're now implicitly searching for a PASS,
| so now you have to operate in degraded mode. The
| unrecognized mechanism could have returned a match or
| no-match, so now the rest of the computation occurs in a
| sort of superposed state.
|
| If the rest of the computation returns a fail, and if the
| unrecognized mechanism was prefixed with a +, then you
| reason that the unrecognized mechanism could've returned a
| match, and so you downgrade the fail to an unknown.
|
| If the rest of the computation returns a pass, and if the
| unrecognized mechanism was prefixed with a -, then you
| reason that the unrecognized mechanism could've returned a
| match, and so you downgrade the pass to an unknown.
|
| Either way you get unknown, so you might as well abort.
The only time it's useful to keep searching is if you do:
first.com: v=spf1 include:second.com a mx -all
second.com: v=spf1 a mx unrecognized -all
At present, "unrecognized" would cause an abort, and the
original "a mx" would not get evaluated.
Degraded mode would then be useful; what you really want is
to continueto search for a pass.
But, in practice, this is just an argument for putting
"include"s and unrecognized mechanisms at the end.
first.com: v=spf1 a mx include:second.com -all
second.com: v=spf1 a mx unrecognized -all
Then the objection scenario becomes:
first.com: v=spf1 a mx include:second.com include:third.com -all
second.com: v=spf1 a mx unrecognized -all
third.com: v=spf1 +all
If we had operated in degraded mode, we would have gotten a
pass out of third.com's include.
If we agree that degraded mode is desirable, we now need a
way to specify that the client should continue to search for
a non-fail result. Previously, "+" and "-" were logically
equivalent. In degraded mode, one is preferable to the other.