Basically, if a mechanism is unknown (whether it's inside an
include or not) you have a choice of aborting or
continuing. Presently, the specification says to abort.
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.
Wait, you only tested two of the possible four options:
unrecognized: + rest of record: fail
unrecognized: - rest of record: pass
Ok, these should be unknown, but what about:
unrecognized: + rest of record: pass
unrecognized: - rest of record: fail
With the current SPF semantics, these would result in an unknown, but it is
plain to see that they should end in pass and fail (respectively).
Another weird thing about the SPF semantics is that it allows unrecognized
modifiers, but not unrecognized mechanisms... Why?
If unrecognized mechanisms are not allowed because SPF is designed to be
"frozen", then why allow unrecognized modifiers? This will lead people to hack
in mechanisms via modifiers like this:
"v=spf1 a mx authextension=auth:server.mydomain.com -all"
If unrecognized modifiers are allowed because SPF is designed to be
"extensible", then why not allow unrecognized modifiers?
I'm not advocating for SPF extensibility, I'm advocating for consistency. I'd
like to know the rationale behind this, and I don't mind being hit by that clue
bat.
Also, if we do go with an extensible SPF, then I think the best way to do it
might be through error handling, since this would also solve the problem that
Lars had with includes (for example, you might want an include that results in
none/unknown/error to be ignored or result in fail).
Michael R. Brumm