Re: What to do about redirect= and NXDOMAIN?

Alex van den Bogaerdt wrote:

> On Sun, May 22, 2005 at 04:12:39PM -0700, Bill Taroli wrote:
>
>  
>
> > I accept the rationale for perhaps not using PermError for this -- 
> > considering your later statement that it might best be reserved for 
> > syntax/usage errors. My compromise to (1) would be to instead consider 
> > having NXDOMAIN result in SoftFail. This would raise awareness of the 
> > problem without (presumably) resulting in the immediate rejections Fail 
> > or PermError might. None seems to me to just be too weak in this case.
> >    
> I think returning softfail is something the publisher doesn't
> know nor wants.
>
> I also think people will just plain reject softfail as they do
> with fail.  Granted, I can't back this statement up, it is just
> a gut-feeling.
>  
This was exactly what I did myself, when I first enabled SPF to be used 
for rejections on my MTA -- Fail & Softfail. When I realized some of the 
conditions for which SoftFail was being returned, I backed off to just 
Fail. The difficult part was that the documentation I read on SPF hadn't 
actually prepared me to understand all the cases where a condition might 
occur. Note I didn't just throw my hands up and say "screw SPF"... but I 
also don't want (as a receiver) to be reacting inappropriately to 
conditions.
I suppose the ultimate answer to this question will boil down to "What 
is this status intended to communicate to a receiver, and is the 
condition consistent with that intent?" Note that I don't ask the 
question "what will the receiver do with this?" but rather "what is the 
spec communicating?"
To me, as a receiver, if SPF says "None" then basically it adds no value 
to my decision to accept a message. If SPF does this in cases where it 
might be useful to know something went wrong, then I might question it's 
usefulness. For example, I've taken the policy of replying on 4xx with 
EHLO lookup failures. Why? Because this has proven to be a very good 
measure of protection against spammers, and it affords me some time to 
receive reports of false positives, raise a flag with the domain 
administrators of the sender, and for them to correct the problem. In 
some cases, I've temporarily put exceptions into my policy where there 
is obviously an error, but that it will take more time than 4xx will 
allow to resolve.
To whit: We cannot assume how receivers will respond to various 
situations. But SPF should be expressive enough to ensure that receivers 
can ultimately make the decision how to react to various situations.
> A domain owner looks at his options, carefully generates a record
> and publishes it. (or at least: this is how it should be done).
>
> When something suddenly fails (the included record is gone, for
> instance), the SPF record doesn't reflect the publishers policy
> anymore.  There is a problem and we have a result for that. This
> result is called PermError.
>
> PermError used to suggest a 5xx error being returned.
>  
I definitely understand the rationale for this, but as a receiving it's 
nice to be able to make the decision myself. If I see conditions 
resulting in PermError that don't fit my image of 5xx, then I may not 
5xx in cases where it might be proper.
> The goal was to describe current behaviour, therefore I am strongly
> against altering the current draft and introducing new, incompatible,
> behaviour.
>
> This isn't fixing a typo or a bug: it modifies the way all current
> SPF records are to be interpreted.
>  
This is an excellent point, and one that I hadn't understood. If this 
draft process is here to merely document a current set of behaviors, 
then debate over how it should behave is pointless.
Bill