Jeroen Massar wrote:
what happens to the case where someone comes up with a really
cool new mechanism, will then the version number of spf be
updated and thus invalidate all the old ones, most likely
requiring people to have both spf1 and spf9 or whatever
Yes, that's possible. "Ignoring unknonwn mechanims" in v=spf1
is a fundamentally flawed idea, e.g. this hypothetical policy:
"v=spf1 +pgp:key.server.example -all"
Implementations ignoring the unknown +pgp would return FAIL.
They tried some tricks like "stop as soon as you don't know
what it is", with an implicit or explicit default result.
For the pgp example the default could be NEUTRAL, but it was
messy. The typical "unknown" mechanisms are simply "typos",
not a cool new idea unfortunately... ;-)
Binary policies is an RMX idea, see Wayne's reply, he does
something in this direction in his implementation. But if
you have e.g. 2 bits for the result and 6 bits for up to 64
mechanisms, then you still can't have whatever new "unknown"
mechanism you like, it would need a number 0..63.
You could also split it into 3 + 5 bits (maybe allowing for
a later HARDPASS, or 2 + 2 + 4 allowing for 4 scopes, plus
4 results, plus 16 mechanisms). It makes sense, but it also
limits the number of mechanisms.
You could also encode op= properties into bits, one byte with
up to 8 properties. But that stuff also requires registries
of _known_ values like option-bits.
When Hadmuth (= the inventor of RMX) finally proposed to use
base64 to encode the resulting binary policy my instincts told
me that this is a bad idea, what you win with binary you lose
again with base64, just sticking to plain text is much better.
Bye, Frank