-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Julian Mehnle wrote:
From a design point of view, there definitely should be no such case
where a given set of SPF records (or just a single SPF record) can
result in both "None" and non-"None" codes. If this is possible, this
indicates the meaning of "None" to be highly unnatural and contrived.
There should be no concept of a "partial policy". If there is _some_
policy, the "None" result code should _not_ be returned. Instead
"PermError" should be returned if the remaining policy (allegedly to be
found at "example.com") cannot be retrieved.
Now, for reasons of consistency, my previous statement, that "redirect=
existent-domain-without-spf-record" returning "None" was perfectly fine,
must be incorrect.
[...]
Yes, "include:" and "redirect=" should behave identically with regard to
non-existent domains and domains without SPF record, respectively:
| non-existent domain | domain w/o SPF record
-----------+---------------------+-----------------------
include: | PermError (throw) | None (no match)
redirect= | PermError | None
Ugh. It is late, and I am contradicting myself. Let's get back to Wayne's
example:
| example.org. TXT "v=spf1 mx -exists:%{ir}.dnsbl.org "
| "redirect=example.com"
| A 192.2.0.1
|
| example.com. A 192.2.1.1
This situation is pretty awful. How, based on common sense, should this be
interpreted? Going from the presupposition that the result of the
evaluation of "redirect=" always is the final result of the overall
evaluation, it is _unavoidable_ to return "None" although some amount of
policy has already been evaluated (but didn't match). That is a very bad
implication.
I think "redirect=" should have never been allowed to be used in
combination with real policy content in the same record. A meaningful
alternative would be:
"v=spf1 mx -exists:%{ir}.dnsbl.org include:example.com"
And, since we cannot declare "v=spf1 $SOME_POLICY redirect=..." to be
syntactically invalid, I think that's how your example should actually be
interpreted.
However, I'm unsure whether and how this massive inconsistency in the
current specification (i.e. returning "None" despite some policy already
having been evaluated) can be resolved without becoming significantly
backwards incompatible.
I'll think more about this tomorrow.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCjoo4wL7PKlBZWjsRAinkAJ9GQR6EdrPZ1qAo3vkAeaHzbjv8TgCgwahC
PvKYhFcbmUvCfNRj88Uy914=
=pBul
-----END PGP SIGNATURE-----