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

[Hector Santos <[e-mail]>]

I believe that would be a FAIL on our left to right natural string 
parser, -ALL would terminate the processing, never see foobar.

I think its correct logic to expect of all.  Don't assume processing 
would be a two-pass parser:

   Pass One: Check Validity of entire line
   Pass Two: Process each string word as its extracted from the line.

I would think the easiest, fastest is just a one pass parser.

Now if the junk is before the EOL (end of line), that is a different 
situation - permerror.

I don't think it would be correct to assume all will read this as a 
permerror when there is a terminator before foobar/junk.

On 4/23/2013 2:21 PM, Murray S. Kucherawy wrote:
> "v=spf1 -all foobar" is syntactically invalid.  I agree with Stuart that it
> should result in "permerror" and not "fail".  Thus, I think 4.6 has it
> right as-is.
>
> Adding text to say anything after "all" MUST be ignored is a good idea as
> well, though they have to be syntactically valid anyway.  Mentally to me,
> this is the same as C and C++ in how they define the short-circuit logic of
> "if" statements.  For example, in "if (foo || bar)", if "foo" is true, C
> and C++ specify that "bar" will not be evaluated.  But if the expression at
> "bar" is actually a syntax error, the whole thing won't compile even if
> everything up to there is fine.
>
> -MSK
>
>
>
> On Tue, Apr 23, 2013 at 2:55 AM, Scott Kitterman <[e-mail]> wrote:
>
>> On Tuesday, April 23, 2013 09:59:25 AM Alessandro Vesely wrote:
>>> On Mon 22/Apr/2013 19:18:58 +0200 Scott Kitterman wrote:
>>>> On Monday, April 22, 2013 06:37:56 PM Alessandro Vesely wrote:
>>>>> On Mon 22/Apr/2013 18:06:41 +0200 Scott Kitterman wrote:
>>>>>> On Monday, April 22, 2013 05:48:33 PM Alessandro Vesely wrote:
>>>>>>> On Mon 22/Apr/2013 16:04:11 +0200 Scott Kitterman wrote:
>>>>>>>>> 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?
>>>>>>>
>>>>>>> Nope, IMHO it's better as is now.  That is:
>>>>>>>
>>>>>>> CURRENT
>>>>>>>
>>>>>>>     If there are any syntax errors
>>>>>>>
>>>>>>> EQUIVALENT-FROM-A-PRAGMATIC-POV
>>>>>>>
>>>>>>>     If any syntax errors are found
>>>>>>>
>>>>>>>     anywhere in the record, check_host() returns immediately with the
>>>>>>>     result "permerror", without further interpretation.
>>>>>>>
>>>>>>> See also http://tools.ietf.org/wg/spfbis/trac/ticket/26
>>>>>>> and
>> http://www.ietf.org/mail-archive/web/spfbis/current/msg02765.html
>>>>>>
>>>>>> Right, but how can you find a syntax error in something you MUST
>> ignore?
>>>>>
>>>>> You have to parse it anyway, as it might be a modifier, e.g.
>>>>>
>>>>>     "v=spf1 a -all ra=rfc6652"
>>>>
>>>> That's true, but as soon as I determine it's a mechanism, I ignore it,
>> so
>>>> the ambiguity still exists.
>>>
>>> If you determine it's a valid something, there's no syntax error.
>>
>> Anyone else?
>>
>> I still think Stuart's point is valid, but I'm not sure the best way to
>> fix it.
>> I also think it would only matter in rare cases, but not so rare we can
>> just
>> say "Meh, corner case." and move on.
>>
>> Scott K
>> _______________________________________________
>> spfbis mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spfbis
>>
>
>
>
> _______________________________________________
> spfbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spfbis
>