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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 21:22:38 -0800

"Overall, when RFC 4408 <http://tools.ietf.org/html/rfc4408> was drafted,
care was taken to capitalize RFC 2119
<http://tools.ietf.org/html/rfc2119>keywords, and use the lower case
words as regular English meaning. While
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?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 Feb 2013 01:35:14 -0500

> 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.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Feb 2013 18:48:22 -0500

> 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."

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

-- 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".

-- 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".

-- 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".

Barry (participatorially)

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Feb 2013 16:13:09 -0500

On Thursday, February 07, 2013 06:48:22 PM Barry Leiba wrote:
> > 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.
> 

Done.

> I don't see what the second paragraph adds to the first, and suggest

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.

> 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.

> the second sentence odd.  I'd make the "MUST ... be" constructions

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?

> is not a comprehensive list of normative requirements."  Otherwise,

Done.

Thanks for the review.

Scott K

---

From: SM <[email-masked]>
Date: Fri, 08 Feb 2013 13:35:39 -0800

>the second sentence odd.  I'd make the "MUST ... be" constructions

The second sentence in Section 5 looks incorrect.  An IPv4-mapped 
IPv6 address is not used for an IPv6 connection.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Feb 2013 16:43:37 -0500

> IPv6 address is not used for an IPv6 connection.

If you're on a pure IPv6 host and you get a connection from ::ffff:192.0.2.1, 
isn't that an IPv6 connection?

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Feb 2013 16:57:05 -0500

> answer is it's a permerror and we want to make that clear.

I think the first paragraph already says what you need.  Maybe a small
tweak to it will make you happier:

OLD
   The check_host() function parses and interprets the SPF record to
   find a result for the current test.  If there are any syntax errors,
   check_host() returns immediately with the result "permerror".

NEW
   The check_host() function parses and interprets the SPF record to
   find a result for the current test.  If there are any syntax errors
   anywhere in the record, check_host() returns immediately with the
   result "permerror", without further interpretation.

...and then remove the second paragraph.  Works?

> Wording suggestions appreciated.

Right, but you start by talking about how many MX lookups there are.
What you say in your explanation above is that there's one, and the
issue is how many A records that expands to.

As written, it seems to say that you can do up to 10 MX lookups, and
each of those can result in up to 10 A lookups, for a total of 110 DNS
lookups.  Is that what you mean?

Are you trying to limit the total number of lookups in an SPF-record
evaluation?  Or just the total number from any one clause?

Maybe this is enough to help you with wording... or maybe when you
answer the questions above, I can take a stab.

> IPv4 mapped IPv6 addresses is an interoperability requirement.  How would you

Just as I said: make them "is", and it works.  Remember that not all
normative text has to have 2119 key words, and this paragraph strikes
me as an example (and, BTW, I would put the record type names in
quotes; it's not bad for "MX" and "AAAA" to lack them, but "A" without
the quotes looks confusing):

NEW-1
   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)
   is still considered an IPv4 address and is evaluated using IPv4 mechanisms
   (i.e. "ip4" and "a").

Or better, I think:

NEW-2
   When any mechanism fetches host addresses to compare with an IPv4
   address, it fetches "A" records; when comparing with an IPv6 address,
   it fetches "AAAA" records.  Even if the SMTP connection uses IPv6, an
   IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) is still
   treated as an IPv4 address and is evaluated using IPv4 mechanisms.

(Modulo your discussion with SM, of course.)

Barry

---

From: SM <[email-masked]>
Date: Fri, 08 Feb 2013 14:21:36 -0800

Hi Scott,
>isn't that an IPv6 connection?

No, as it is an IPv4 connection.  The IP address format is useful to 
make the application protocol independent.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Feb 2013 19:32:18 -0500

On Friday, February 08, 2013 02:21:36 PM SM wrote:
> >If you're on a pure IPv6 host and you get a connection from
> >::ffff:192.0.2.1, isn't that an IPv6 connection?
> 

OK.  I do think it's important that people know to use the ip4: mechansim for 
mapped addresses.  How would you word it?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 08 Feb 2013 19:51:23 -0500

On Friday, February 08, 2013 04:57:05 PM Barry Leiba wrote:
> >  - If the number of a records is =< 10, then do a lookups to find the
> >relevant>
> > IP addresses
> >

Yes.  This is the basis for the infamous 111 DNS lookups.

> evaluation?  Or just the total number from any one clause?

For a single term (clause).

> answer the questions above, I can take a stab.

Please do.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Feb 2013 23:20:23 -0500

>> > relevant IP addresses
...
> For a single term (clause).

OK, let's try this:

OLD
   When evaluating the "mx" mechanism, the number of MX resource records
   queried MUST NOT exceed 10.  If the evaluation of an "mx" mechanism
   results in more than 10 A resource records to be queried, the "mx"
   mechanism MUST produce a "permerror" result.

NEW
   When evaluating the "mx" mechanism, the number of "MX" resource
   records queried MUST NOT exceed 10, and the evaluation of each "MX"
   record MUST NOT result in querying more than 10 "A" resource records.
   If either of these limits is exceeded, the "mx" mechanism MUST produce a
   "permerror" result.

Does that work?

Barry

---

From: SM <[email-masked]>
Date: Fri, 08 Feb 2013 21:36:16 -0800

Hi Scott,
>mapped addresses.  How would you word it?

I'll look up how this is usually handled and sent text.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Feb 2013 01:35:49 -0500

On Friday, February 08, 2013 09:36:16 PM SM wrote:
> >OK.  I do think it's important that people know to use the ip4: mechansim
> >for mapped addresses.  How would you word it?
> 
Thanks,

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Feb 2013 01:43:44 -0500

>    If either of these limits is exceeded, the "mx" mechanism MUST produce a

Close.  There is an overall limit for mechanisms that cause DNS lookups to 10 
of which 'mx' is only one type.  You can't have 10 'mx', 10 'a', and 10 
'include'.  Perhaps:

>    records queried is included in the overall limit of 10 mechanisms/
>    modifiers the cause DNS look ups described above.  The evaluation of each
>    "MX" record MUST NOT result in querying more than 10 "A" resource
>    records.  If this limit is exceeded, the "mx" mechanism MUST produce a
>    "permerror" result.

How's that?  The overall limit of 10 mechansims/modifiers is in the previous 
paragraph.

Scott K

---

From: SM <[email-masked]>
Date: Sat, 09 Feb 2013 02:28:03 -0800

Hello,

Section 5 of draft-ietf-spfbis-4408bis-10 has the following:

   '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").'

The requirement is incorrect.  I did not understand what "host 
addresses" means.  One of the problems is that the discussion is not 
about the IP-layer protocol which is used; it is about how IP 
addresses are handled by an application.  One alternative is to drop 
the paragraph.

Another alternative is:

    Some mechanisms designate IP addresses to be compared against the
    IP address of the SMTP client; A RRs are fetched if the SMTP client
    is using IPv4; AAAA RRs are fetched if the SMTP client is using IPv6.

Regards,
-sm

---

From: S Moonesamy <[email-masked]>
Date: Fri, 08 Feb 2013 23:57:00 -0800

>    If either of these limits is exceeded, the "mx" mechanism MUST produce a

Thanks to Barry Leiba for the review.

As background information there was some discussion last year about 
having DNS lookup limits together ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html ).

Section 5.4 of RFC 4408 mentions that:

   "To prevent Denial of Service (DoS) attacks, more than 10 MX names
    MUST NOT be looked up during the evaluation of an "mx" mechanism
    (see Section 10).  If any address matches, the mechanism matches."

 From Section 10.1:

   "When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there
    MUST be a limit of no more than 10 MX or PTR RRs looked up and checked."

The requirements ("MUST", etc.) are confusing.  The "new" text 
mentions "A" RRs.  It should also cover "AAAA" RRs.

My reading of the rationale is that it is to limit the number of DNS 
lookups.  Wouldn't it be easier to explain this in terms of DNS 
lookups?  The implementation can keep a counter of the number of DNS 
lookups and the function handling DNS can return the appropriate 
result (not SPF result).

Murray Kucherawy commented on this at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03162.html  Is 
the concern the number of DNS lookups or how to prevent a different 
SPF result from being returned?

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 09 Feb 2013 12:54:02 +0100

> Yes.  This is the basis for the infamous 111 DNS lookups.

Can't we remove those paragraphs, please?  They're just misplaced, and
break the One Definition Rule.  I'd propose something like:

 The "mx" and "ptr" mechanisms, and the %{p} macro, are subject to
 their own limits, as specified in the corresponding sections below,
 which are in addition to the lookup limits specified in this section.

 NOTE:
   The limit for "mx" (Section 5.4) is treated differently from the
   limit for "ptr" and the %{p} macro (Section 5.5).  The reason for
   that disparity is that the set of and contents of the MX record
   are under control of the domain owners, while the set of and
   contents of PTR records are not always delegated and can thus be
   under control of their network providers.

Text like that could replace all of the four central paragraphs of
Section 4.6.4.

BTW, Section 5.5 should recall that part of it is also valid for the
%{p} macro.

jm2c

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Feb 2013 07:42:25 -0500

>SPF result from being returned?

Not in a way that's backward compatible. 

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Feb 2013 07:46:04 -0500

>BTW, Section 5.5 should recall that part of it is also valid for the

We can't organise it like that because they are part of an overall 10 lookuplimit that is not per mechanism. 

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Sat, 9 Feb 2013 09:48:36 -0500

> How's that?  The overall limit of 10 mechansims/modifiers is in the previous

I like that; thanks.

b

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Feb 2013 10:51:56 -0500

>     is using IPv4; AAAA RRs are fetched if the SMTP client is using IPv6.
That rather looses the point about IPv4 mapped addresses.  It's in there 
specifically because people were getting it wrong.  I'm happy to word it in a 
better way, I think we need to be explicit on the subject.

Scott K

---

From: SM <[email-masked]>
Date: Sat, 09 Feb 2013 08:46:39 -0800

Hi Scott,
>better way, I think we need to be explicit on the subject.

Ok.

I would have missed the issue if Barry Leiba did not comment about 
that text.  I spent some time going through various RFCs related to 
the subject.  I concluded that it was easier to avoid the subject of 
"IPv4-mapped IPv6 address" as it is not easy to fix.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 09 Feb 2013 12:07:50 -0500

On Saturday, February 09, 2013 08:46:39 AM SM wrote:
> >specifically because people were getting it wrong.  I'm happy to word it in
> >a better way, I think we need to be explicit on the subject.
> 
> Ok.
> 

I don't think not mentioning it is a good option.  I'll figure something out.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 10 Feb 2013 00:42:27 -0500

On Saturday, February 09, 2013 09:48:36 AM Barry Leiba wrote:
> > Close.  There is an overall limit for mechanisms that cause DNS lookups to
> > 10 of which 'mx' is only one type.  You can't have 10 'mx', 10 'a', and
> > 10> 
> > 'include'.  Perhaps:
> > How's that?  The overall limit of 10 mechansims/modifiers is in the
> > previous paragraph.
> 
> I like that; thanks.

Thanks.  Done locally for -11.  Made parallel changes for the PTR processing 
limit description too.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 10 Feb 2013 01:01:07 -0500

On Friday, February 08, 2013 04:57:05 PM Barry Leiba wrote:
> > 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:
> > 
> > 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.
> 

Done for -11.

> answer the questions above, I can take a stab.

Done already, down thread.

> > 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?
> 
>    is still considered an IPv4 address and is evaluated using IPv4
> mechanisms (i.e. "ip4" and "a").
> 
> Or better, I think:
> 
> NEW-2

Added quotes to the results of the discussion down thread.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 11 Feb 2013 11:14:01 +0100

On Sun 10/Feb/2013 07:01:07 +0100 Scott Kitterman wrote:
>> [...]
>> (and, BTW, I would put the record type names in quotes; it's not
>> bad for "MX" and "AAAA" to lack them, but "A" without the quotes
>> looks confusing):
>> 
>>    When any mechanism fetches a host address to compare with an IPv4
>>    address, it fetches "A" record [...
>>                                slightly changed to stress ambiguity]
> 

I'd avoid quoting record types /systematically/:  Having "MX" and "mx"
for the record type and the mechanism is confusing too.  I'd prefer
"it fetches a type A record" for the case quoted.  Most occurrences
are not ambiguous and need no change.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 Feb 2013 07:31:21 -0800

I don't agree that there's any confusion between the record types and the
mechanism names.  I think the context of use in each case makes that clear.

As for quoting, doesn't adding the article (a la: an A record) make that
clear as well?

-MSK

On Mon, Feb 11, 2013 at 2:14 AM, Alessandro Vesely <[email-masked]> wrote:

> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>