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.
[current domain]
The Section 5.1 "redirect" doesn't explicitly say this, but
does note that redirects can be chained.
That's another potential problem, in Weng's per user policy...
| "v=spf1 mx" ... "redirect=%{l1r+}._at_.%{o}._spf.%{d}"
...he can have %{o} != %{d}. Here I expected that this could
be a case of...
| foobox.com has a sender policy "v=spf1 redirect=pobox.com"
...and %{d} == pobox.com set by the redirection. Now if you
say that this is unclear my foobox.com idea was dubious, it
should be (for foobox.com) "v=spf1 include:pobox.com ?all".
IMHO an evaluation of redirect=x should result in %{d} == x,
just like an evaluation of include:x results in %{d} == x.
only the exp= modifier has the following text:
Note: during recursion into an Include mechanism,
explanations do not propagate out.
IMHO the exp= modifier should be deleted by MARID, it's a PITA.
Recipients don't want weird explanations of the senders, they
want a clear PASS / DONTKNOW / FAIL. Of course exp= texts do
not propagate out, because exp= mainly explains FAIL (and maybe
DONTKNOW), but include: handles mainly PASS (and maybe ERROR).
I think this needs to be clarified in the SPF spec.
Yes, three potential problems:
1 - is a redirected PASS good enough for included redirections:
IMHO yes, but maybe you have an example where this won't
work as expected.
2 - do redirections set %{d} like inclusions: again IMHO yes,
because %{d} is only a shorthand for "domain of the actual
SPF record" (minus _ep. prefix, irrelevant for classic SPF)
3 - only because it's syntactically possible I'd still like to
know what -include:x / ~include:x / ?include:x really do
if somebody uses it.
Bye, Frank