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

[Scott Kitterman <[e-mail]>]

On Tuesday, January 12, 2016 05:09:35 PM Alessandro Vesely wrote:
> Hi,
> RFC 7208 doesn't seem to be very clear on the requirements for "exists"
> mechanisms.  I don't know if that deserves an errata.
> 
> The spec defines mechanisms, but Section 4.6.4 "DNS Lookup Limits" does not
> mention "exists", while Section 5.7 "exists" does not mention return values.
> 
> OTOH, dmarcian reports that "exists" mechanisms are not fully supported by
> all high-volume receivers.  In fact, google.com returns permfail for the
> record in the first bullet of Appendix D.1, unless a match is found before
> "exists".
> 
> According to Section 2.6.7 "Permerror", Google signal an error condition
> that definitely requires DNS operator intervention to be resolved. Tools
> which parse DMARC aggregate feedback correctly report an issue, to no avail
> :-O
> 
> You see,  SPF receivers are divided into two categories: those with a loaded
> check_host() function and those who never reject on fail.  Google never
> reject on fail.  Why do they return permerror, then?  Wouldn't "none" be
> fine?
> 
> 4.6.2.  *Mechanisms*
> 
> The second paragraph there may be a good point to pin an errata:
> 
> OLD
>    When a mechanism is evaluated, one of three things can happen: it can
>    match, not match, or return an exception.
> 
> 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 way the RFC is designed, mechanisms aren't optional.  What you're asking 
for is not something that should be done via errata.  4.6.2 is correct and 
exists is no different than any other mechanism.

Scott K