-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wayne Schlitt wrote:
Julian Mehnle writes:
Wayne Schlitt wrote:
[...] I still think it is confusing to have example.org having an
SPF record, but when evaluated, it results in "None".
But in that case, "None" is absolutely correct. example.org has not
published an SPF policy. It may have published an SPF _record_ that
is effectively meaningless, but it has not published a policy.
Ok, lets make this more explicit:
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
No, it is my opinion that example.org *has* published a sender policy
and that this sender policy can return "Pass" (mx match) "Fail"
(exists match) or "None" (redirect).
Now it's getting esoteric -- not because of the example being a corner case
(it probably really isn't), but because of the inherently limited
expressiveness of the result codes.
- 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.
However, to back up a second, Stuart just posted that he thinks that
include and redirect already defined to act the same. I would like to
confirm that you are saying that they don't.
"include:" and "redirect=" are _not_ defined to act the same, neither
explicitly (follows directly from the spec) nor implicitly, with regard to
non-existent-domain and existent-domain-without-spf-record. This is what
the spec says on the matter:
[
check_host(non-existent-domain) == "None"
check_host(existent-domain-without-spf-record) == "None"
]
| 5.2. "include"
|
| [...]
|
| The "include" mechanism triggers a recursive evaluation of
| check_host(). The domain-spec is expanded as per Section 8. Then
| check_host() is evaluated with the resulting string as the <domain>.
| The <ip> and <sender> arguments remain the same as in the current
| evaluation of check_host().
|
| [...]
|
| Whether this mechanism matches, does not match, or throws an error,
| depends on the result of the recursive evaluation of check_host():
|
| +---------------------------------+---------------------------------+
| | A recursive check_host() result | Causes the "include" mechanism |
| | of: | to: |
| +---------------------------------+---------------------------------+
| : ... : ... :
| | None | throw PermError |
| +---------------------------------+---------------------------------+
Thus, both "include:non-existent-domain" and "include:existent-domain-
without-spf-record" yield "PermError".
| 6.1. redirect: Redirected Query
|
| If all mechanisms fail to match, and a "redirect" modifier is
| present, then processing proceeds as follows: [...]
|
| The domain-spec portion of the redirect section is expanded as per
| the macro rules in Section 8. Then check_host() is evaluated with
| the resulting string as the <domain>. The <ip> and <sender>
| arguments remain the same as current evaluation of check_host().
|
| The result of this new evaluation of check_host() is then considered
| the result of the current evaluation.
Note the last paragraph in particular.
Thus, both "redirect=non-existent-domain" and "redirect=existent-domain-
without-spf-record" yield "None".
q.e.d.
"include:" and "redirect=" acting differently seems to be subliminally
justified with their different purposes, as taken from the last paragraph
of section 5.2, "include". I don't think this is a good justification.
Although Stuart's statement does _not_ follow from the current spec (as
shown above), I can very well follow his logic:
Stuart D. Gathman wrote:
The rationale for non-existent include resulting in PermErr was that the
policy could not be evaluated, and the problem was not going to go away
until someone fixed it. The same rationale applies to redirect, even
though not explicitly stated.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCjoOqwL7PKlBZWjsRAnwlAJ9yVHuAkey8ixLSTcLq8FUCWETqbQCfY4QF
WSi5zECf9SZdSFwrEWeWXGE=
=1sfu
-----END PGP SIGNATURE-----