Re: [spfbis] Result of record evaluation with non-implemented mechanism

[Alessandro Vesely <[e-mail]>]

Hi SM,

On Thu 14/Jan/2016 16:36:41 +0100 S Moonesamy wrote: 
> At 08:09 12-01-2016, Alessandro Vesely wrote:
>>
>> NEW
>>    When a mechanism is evaluated, one of three things can happen: it can
>>    match, not match, or return an exception.  Non-implemented mechanisms
>>    MUST NOT return an exception.
>>
>> Better ideas?
> 
> The suggested text is about non-implemented mechanisms.  There is a "do not
> use" mechanism.  Would that be a non-implemented mechanism?  There isn't an
> explanation for the "MUST NOT" in the suggested text.

Yeah, that would have been a bit freaky.  Yet, a cute evaluator could optimize
an evaluation in some ways.  Consider a record ending like so:

   ...   ?exists:%{ir}.blah ?all

There is no reason to evaluate the exists.

Now what if you had:

   ...   ?exists:%{ir}.blah -all

Suppose you know your internal policy only differentiates between "pass" and
"not-pass".  Getting "neutral" or "fail" wouldn't make a real difference,
except for the formal result name that you write on reports.  Does it really
hurt to put "none" as in "nothing relevant here"?  The note at the end of
Section 4.8 seems to allow some leeway in the reported result, but only for
malformed names.

There are some other head-scratchers before the example in the first bullet of
Appendix D.1 can be used in practice.  One is the query quota that a whitelist
may impose.

Let me use this post as an occasion to apologize to Google for having wrongly
imagined that their implementation skips proper evaluation of mechanisms.  In
fact, the resulting DNS queries fail precisely because it doesn't.

Ale