In <40F2DD82(_dot_)1239(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
wayne wrote:
[Roger's example of an included redirection]
| example.com. TXT "v=spf1 include:inc.example.com ip4:192.168.1.3 -all"
| inc.example.com. TXT "v=spf1 ip4:192.168.1.1 redirect=red.example.com"
| red.example.com. TXT "v=spf1 ip4:192.168.1.2"
My interpretation from the standard is that, yes, the
included record should execute the redirect, but the
redirection will not propogate out to the top level SPF
record.
In other words, in your interpretation 192.168.1.2 is _not_
allowed to send MAIL FROM example.com. That's not what I'd
expect, because 192.168.1.2 results in a PASS, and inclusions
look for a PASS (or ERROR), only ?/~/- are ignored.
No, my interpretation is that 192.168.1.2 *is* allowed to send MAIL
FROM example.com.
The first check for example.com is for the include:, which starts a
new query.
The first (and only) check for inc.example.com is an ip4: that doesn't
match. Since nothing matches, the redirect= is run as a new query,
but the query for inc.example.com is finished.
The first (and only) check for rec.example.com is for an ip4: which
*does* match 192.186.1.2 and thus passes.
This pass means that the include: passes
Thus the final result is pass.
The point is the redirect is done during the inc.example.com query.
The redirect= modifier value is not passed up to the example.com query
and done there.
So, say we had the following records:
example.com. TXT "v=spf1 include:inc.example.com -ip4:192.168.1.2 -all"
inc.example.com. TXT "v=spf1 ip4:192.168.1.1 redirect=red.example.com"
red.example.com. TXT "v=spf1 ip4:192.168.1.2"
In this case, the result would still pass because the redirect is done
at the inc.example.com level. If it has been done at the example.com
level, the -ip4: mechanism would match and thus the result would be
fail.
-wayne