Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14 - Fully parse record *first*

[Scott Kitterman <[e-mail]>]

I don't think so.  An included record only gets match/notmatch or some error.  
The qualifier for the 'all' mechanism in the included record doesn't enter into 
it.

Scott K

On Monday, April 22, 2013 07:40:14 AM Kurt Andersen wrote:
> That leaves the ambiguity of handling -all in embedded (include:) records.
> What should be done if the sample foobar mechanism is being referenced in
> an included record?
> 
> --Kurt
> 
> On Mon, Apr 22, 2013 at 7:04 AM, Scott Kitterman <[e-mail]> wrote:
> > On Sunday, April 21, 2013 09:21:42 PM Stuart Gathman wrote:
> > > On 04/17/2013 12:50 AM, S Moonesamy wrote:
> > > > As Scott mentioned, things have been very quiet for this WGLC.  It
> > > > helps if there are people who read the draft as you did above as I can
> > > > determine whether the working group reviewed the draft and is ok with
> > 
> > it.
> > 
> > > Minor nit:
> > > 
> > > Section 5.1
> > > 
> > > Mechanisms listed after "all" MUST be ignored.
> > > 
> > > Sure, section 4.6 says
> > > 
> > > If there are any syntax errors
> > > 
> > >     anywhere in the record, check_host() returns immediately with the
> > >     result "permerror", without further interpretation.
> > > 
> > > But an implementer could misinterpret this as saying the following
> > > should get Fail rather than PermError:
> > > 
> > > v=spf1 mx -all foobar
> > > 
> > > Section 4.6 doesn't make it clear you have to parse everything
> > > (returning permerror on syntax errors), and only *then* interpret. The
> > > wording makes it sound like you could parse and interpret one term at a
> > > time, stopping when you get a match or syntax error.
> > 
> > I would tend to favor the MUST be ignored over the returns immediately
> > with a
> > permerror (yielding the opposed view of the preferred result from yours).
> > 
> >  I
> > 
> > think this confirms there's an ambiguity in the current draft.
> > 
> > If I take your view that it's better to raise the error (unknown
> > mechanism),
> > the perhaps changing the 5.1 language would help.  Adding the sentence
> > before
> > 
> > in, for more context:
> > > Mechanisms after "all" will never be tested.  Mechanisms listed after
> > 
> > "all"
> > 
> > > MUST be ignored.
> > 
> > Perhaps if we combine those it helps:
> > > Mechanisms after "all" MUST not be tested.  Mechanisms listed after
> > > "all"
> > > will be ignored for all purposes except syntax error evaluation.
> > 
> > Does that help?
> > 
> > Scott K
> > _______________________________________________
> > spfbis mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spfbis