Re: [spfbis] Revisit: Issue #36: RFC 2119 key words

[Scott Kitterman <[e-mail]>]

On Thursday, February 07, 2013 06:48:22 PM Barry Leiba wrote:
> >> most of the lower case words have been changed to synonyms, a few have
> >> been
> >> changed into RFC 2119 <http://tools.ietf.org/html/rfc2119> keywords. I
> >> think most (but sadly, not all) of these capitalizations are wrong."
> >> 
> >> Could this be made more specific?  Which ones are wrong?
> > 
> > Unfortunately Arthur hasn't been very active lately, so I was hoping
> > someone experienced with RFC lawyering could have a look and see if there
> > were any they felt were wrong.  I've already gone back and fixed several
> > that I concluded in retrospect were wrong.
> 
> There aren't many wrong ones, I think.  Here's what I found in a brief
> pass through:
> 
> -- Section 4.5 --
>    Starting with the set of records that were returned by the lookup,
>    discard records that do not begin with a version section of exactly
>    "v=spf1".  Note that the version section is terminated either by an
>    SP character or the end of the record.  A record with a version
>    section of "v=spf10" does not match and MUST be discarded.
> 
> This "MUST" seems out of place, because there's no "MUST" in the first
> sentence.  I think you should make it "and is discarded."

Done.

> -- Section 4.6 --
> I don't see what the second paragraph adds to the first, and suggest
> eliminating it.

That particular text is unchanged from RFC 4408.  IIRC, the reason it is there 
was there was some question back in the day about how processing should work.  
As an example:

You get a message from a domain what has this SPF record:

v=spf1 a:relay.example.com foo:bar.example.com -all

This is a syntactically invalid record because there is no mechanism foo.  The 
question the second paragraph was meant to address is, "What is the correct 
result for a message from relay.example.com?"  It's either pass (strict left 
to right processing) or permerror (all errors must be detected).  The correct 
answer is it's a permerror and we want to make that clear.

My preference would be to leave it alone, but I'm open to suggestions for 
better wording.

> -- Section 4.6.4 --
> In the second paragraph, why are you mixing "MX resource records" in
> the first sentence with "A resource records" in the second sentence?
> Is this a typo, or intentional?  If it's intentional, I would re-word
> it, which will probably correct the odd "MUST".

What I was trying to communicate there is something like the following 
sequence:

 - Do mx lookup for the domain.
 - One or more a records returned
 - If the number of a records is =< 10, then do a lookups to find the relevant 
IP addresses
 - If the number of a records is > 10, don't do any lookups and return a 
permerror.

When I look at it, I think it says that, but obviously it's not clear.  
Wording suggestions appreciated.

> -- Section 5 --
>    When any mechanism fetches host addresses to compare with <ip>, when
>    <ip> is an IPv4 address, A records are fetched; when <ip> is an IPv6
>    address, AAAA records are fetched.  Even if the SMTP connection uses
>    IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5)
>    MUST still be considered an IPv4 address and MUST be evaluated using
>    IPv4 mechanisms (i.e. "ip4" and "a").
> 
> Again, the lack of "MUST" in the first sentence makes the use of it in
> the second sentence odd.  I'd make the "MUST ... be" constructions
> into "is".

The construction I'm going for here is:

if $CONDITION then MUST $STUFF

It didn't strike me as odd, but I guess it is.  Using the IP4: mechanisms for 
IPv4 mapped IPv6 addresses is an interoperability requirement.  How would you 
suggest going about it?

> -- Section 10 --
> The "SHOULD" in the first paragraph is wrong.  If what you want to say
> is that the section isn't normative, then say it that way, as "and it
> is not a comprehensive list of normative requirements."  Otherwise,
> just make it "should".

Done.

Thanks for the review.

Scott K