Subject: Re: [spfbis] Secetion 4.6.4 DNS Lookup Limits

From: Arthur Thisell <[email-masked]>
Date: Tue, 11 Sep 2012 12:52:57 -0700 (PDT)

> The question I would ask is why is this change necessary and what is the 
> impact on RFC 4408 implementations.

Yes, I think you have the right approach.  However, you then went on to give these examples:

>  'When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
>   there MUST be a limit {...}

That is new text to RFC 4408bis and it is wrong.  The spirit is right, but the new text breaks both ptr: and %{p}.

>  'Minimizing the DNS resources required for SPF lookups can be done by
>   {...}  {table snipped}

That is new text to RFC 4408bis and it is wrong.  Now, apparently non-normative sections of an RFC can contradict normative sections, but you can't really use non-normative sections to say how normative sections should be.

Let's try this from RFC 4408:

>   Implementations MAY choose to parse the entire record first and
>   return "PermError" if the record is not syntactically well formed.
>   However, in all cases, any syntax errors anywhere in the record MUST
>   be detected.

Now, it can be debated whether too many mechanism is a syntax error or not, but the spirit is that errors that can be detected early, must be detected early.  Basically, the XML model of strict checking rather than the tag soup model of HTML.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 11 Sep 2012 17:44:51 -0400

On Tuesday, September 11, 2012 12:52:57 PM Arthur Thisell wrote:
> Now, it can be debated whether too many mechanism is a syntax error or not,
> but the spirit is that errors that can be detected early, must be detected
> early.  Basically, the XML model of strict checking rather than the tag
> soup model of HTML.

My initial thought for the start of this message was to quote this section as 
well.  Right to left parsing with errors only if the error condition is 
triggered is a recipe for what appears to be random failures when a record 
works some times and not others.

In any case prohibiting total record error detection and requiring left to 
right processing would be a substantiative change to the protocol.  I don't 
think it would be a good one either.

Scott K