Re: What to do about redirect= and NXDOMAIN?

wayne wrote:

> Julian and I chatted about this some on the #spf IRC channel today. [...]
>
> Recall that the current semantics are:
>
>             | non-existent domain | domain w/o SPF record
>  -----------+---------------------+-----------------------
>   include:  | PermError (throw)   | PermError (throw)
>   redirect= | None                | None    
>
>  
>
> > So this what I think we should do:
> >
> >             | non-existent domain | domain w/o SPF record
> >  -----------+---------------------+-----------------------
> >   include:  | PermError (throw)   | None* (no match)
> >   redirect= | PermError*          | None / Neutral*
> >
> > (* marks differences from the current specification.)
> >    
> Besides the above matrix of results, Julian also said that the
> following might be ok with him:
>
>             | non-existent domain | domain w/o SPF record
>  -----------+---------------------+-----------------------
>   include:  | PermError (throw)   | PermError (throw)
>   redirect= | PermError*          | PermError (throw)*
>
>  (* marks differences from the current specification.)
>
>
> I would like to also suggest the following:
>
>             | non-existent domain | domain w/o SPF record
>  -----------+---------------------+-----------------------
>   include:  | PermError (throw)   | PermError (throw)
>   redirect= | Neutral*            | Neutral*
>
>  (* marks differences from the current specification.)
>
> As Shew pointed out on #spf, one major difference between include: and
> redirect= is that include: can be found in the middle of an SPF
> record, and it is important to stop evaluations at that spot, rather
> than continue on into mechanisms that aren't intended.  The redirect=
> modifier, however, is only executed at the very end, and is therefore
> much more similar to the existing default of "?all" if nothing matches.
After consulting 
<http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre7.html#op-result> 
(there seem to be so many drafts around!), I like either SoftFail or 
PermError for the "redirect=" cases. A few things to consider about 
redirect=:
 - It is used instead of "all", to be more specific about what policy 
should apply instead of throwing our hands up
 - It is defined as being applicable between domains under the /same 
administrative control/.
I totally agree None is too wimpy in this case, but I wonder if Neutral 
is any better. Neutral is defined as an explicit statement of 
neutrality, which this case doesn't seem to fit. I can't imagine where 
"?redirect=" would make sense.
But why SoftFail? From the spec, SoftFail says, "The domain believes the 
host isn't authorized but isn't willing to make that strong of a 
statement." That seems to fit with this condition a good deal more than 
an explicit neutral statement, and yet still falls short of calling it 
an out-an-out error -- if PermError is objectionable in this case. The 
spec was pretty light on any explanation for why one might prefer one or 
the other: "Checking software SHOULD treat [PermError] similar to the 
'SoftFail' result".
If I publish a policy that says "My policy for example.org is that of 
nxdomain.example.com," (a domain I am presumed to administrate, per the 
spec) then what is it I'm saying? I've certainly done more than not 
publish a record. I haven't explicitly stated that I'm neutral regarding 
nxdomain. I could just have easily used 
"redirect=ha.ha.ha.youll.never.find.this.net". SoftFail embodies the 
uncertainty of the outcome and yet implies there is something that 
requires additional review before understanding whether this is really 
something objectionable. If PermError is sufficiently distinguishable 
from SoftFail, then I might lean that direction.
The bottom line is that if I publish a redirect between two domains that 
I am presumed to administrate (per the spec) and the target is either 
NXDOMAIN or has no SPF record, then we have a problem Mr. Spock. And 
rather than just ignore it as None or Neutral, the receiver should have 
some indication of this problem... even to the extent that they may wish 
to act upon it. SoftFail and PermError do seem to be appropriate in this 
case.
Bill

Bill