-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
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.
As well they should. I don't think this is the best example
for your point, as it is a flawed policy. Were I running
that domain (assuming the 'pgp' modifier is not universally
available but sometimes so) I would set the policy as something
like "v=spf1 +pgp:key.server.example ?mx:example -all" to prevent
outright forgeries, but not make explicit claims about e-mails
that might be good but are otherwise unverified.
I do think the point about message signing being outside the
scope of SPF verifiable quanities has some weight though.
It makes the most sense to me for the SPF implementation
to return the result of the first match it hits. An unknown
mechanism will never be a match.
- --
Daniel Taylor
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCpFyp8/QSptFdBtURAlmLAJ9O4Q1ZUqcZFunrJQTv77RjYV99VQCfRKEY
BDGtUiEB9bN+Rb+nEAuleDE=
=ISdC
-----END PGP SIGNATURE-----