Subject: [spfbis] remove section 9.1.1 DNS Resource Considerations

From: Arthur Thisell <[email-masked]>
Date: Sat, 8 Sep 2012 08:21:42 -0700 (PDT)

"We should forget about small efficiencies, say about 97% of the time: 
      premature optimization is the root of all evil" - Donald Knuth

I'm slow sometimes, but I've come to the conclusion that we should remove section 9.1.1 (DNS Resource Considerations)

First, most of this information is duplicated from other parts of the draft.  Section 4.6.4 (DNS Lookup Limits) contains the DNS limits, section 3 (SPF records) already says "ADMDs SHOULD also try to minimize the amount of other DNS information needed to evaluate a record."

In particular, the table in section 9.1.1 can be easily misread as saying that you can have 10 a: mechanisms *and* 10 mx: mechanisms, *and* 10 include: mechanisms.  While I initially liked the table, I now think it adds more confusion that clarity.  Maybe the table can be redesigned, but no matter what, it should be in section 4.6.4.

Second, SPF adoption isn't hampered so much by a few extra DNS queries as much as it is by people having out of date SPF records.   Too many people try to get clever and turn an mx: mechanism into a series of ip4: mechanisms and then forget to update the SPF record when something changes.

This section gives undue emphasis on efficiency over reliability.

Third, this is basically a "how to" document that would be much better served by existing or new web pages/books.

Last, if you really want to reduce the number of SPF queries, it would be much more effective to dust off that SPF record optimizer someone wrote long ago and try to get it put into the bind distribution.  Make it easy to get it incorporated into godaddy's SPF support and get it running there.  The SPF spec is not an effective place to promote this kind of thing.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 08 Sep 2012 11:32:35 -0400

On Saturday, September 08, 2012 08:21:42 AM Arthur Thisell wrote:
> I'm slow sometimes, but I've come to the conclusion that we should remove
> section 9.1.1 (DNS Resource Considerations)
> 
> First, most of this information is duplicated from other parts of the draft.
>  Section 4.6.4 (DNS Lookup Limits) contains the DNS limits, section 3 (SPF
> records) already says "ADMDs SHOULD also try to minimize the amount of
> other DNS information needed to evaluate a record."
> 
> In particular, the table in section 9.1.1 can be easily misread as saying
> that you can have 10 a: mechanisms *and* 10 mx: mechanisms, *and* 10
> include: mechanisms.  While I initially liked the table, I now think it
> adds more confusion that clarity.  Maybe the table can be redesigned, but
> no matter what, it should be in section 4.6.4.
> 
> Second, SPF adoption isn't hampered so much by a few extra DNS queries as
> much as it is by people having out of date SPF records.   Too many people
> try to get clever and turn an mx: mechanism into a series of ip4:
> mechanisms and then forget to update the SPF record when something changes.
> 
> Third, this is basically a "how to" document that would be much better
> served by existing or new web pages/books.
> 
> Last, if you really want to reduce the number of SPF queries, it would be
> much more effective to dust off that SPF record optimizer someone wrote
> long ago and try to get it put into the bind distribution.  Make it easy to
> get it incorporated into godaddy's SPF support and get it running there. 
> The SPF spec is not an effective place to promote this kind of thing.

I have seen people have significant problems with figuring out how to count the 
lookups to find out of their records would generate permerror or not.  Some of 
this text goes towards solving that problem as well.  Do you think that would 
be worth preserving?

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 09 Sep 2012 13:43:19 +0200

On Sat 08/Sep/2012 17:21:42 +0200 Arthur Thisell wrote:
> 
> In particular, the table in section 9.1.1 can be easily misread as
> saying that you can have 10 a: mechanisms *and* 10 mx: mechanisms,

Perhaps that fixes it:

OLD
   Section 4.6.4 specifies the limits receivers have to use.

NEW
   Limits are specified in Section 4.6.4.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 9 Sep 2012 09:44:05 -0700

>    Limits are specified in Section 4.6.4.

Those are synonymous to me, other than the fact that the burden is not
clearly on receivers.  Is that the intent?

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Sep 2012 10:04:29 -0700

> clearly on receivers.  Is that the intent?

The old language is pseudo-normative.  Not formally normative, but 
semantically very much reads as normative.  The proposed text is 
cleaner, IMO.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net