Subject: [spfbis] [Technical Errata Reported] RFC7208 (6595)

From: RFC Errata System <[email-masked]>
Date: Thu, 3 Jun 2021 02:35:33 -0700 (PDT)

The following errata report has been submitted for RFC7208,
"Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6595

--------------------------------------
Type: Technical
Reported by: Benjamin Schwarze <[email-masked]>

Section: 4.6.4

Original Text
-------------
As described at the end of Section 11.1, there may be cases where it
is useful to limit the number of "terms" for which DNS queries return
either a positive answer (RCODE 0) with an answer count of 0, or a
"Name Error" (RCODE 3) answer.  These are sometimes collectively
referred to as "void lookups".  SPF implementations SHOULD limit
"void lookups" to two.  An implementation MAY choose to make such a
limit configurable.  In this case, a default of two is RECOMMENDED.
Exceeding the limit produces a "permerror" result.

Corrected Text
--------------
-- Addition to the original paragraph --

ADMDs should be aware that the void lookup limit can easily be exceeded by using sender-specific macros ("s", "l", "o", "i", "h") in more than 2 terms.

The following example will lead to an permerror in the most implementations if the <ip> is not found in any of the lists:
  v=spf1 exists:%{ir}.list1.example.net exists:%{ir}.list2.example.net exists:%{ir}.list3.example.net -all

Notes
-----
In addition to the above suggestion, I still see a contradiction between the "void lookup limit" and the "exists" mechanism. The functionality of "exists" includes (in my opinion) the negative response (RCODE 3). But the "void lookup limit" allows this to occur only twice. This limits the use of "exists" very much.

Admittedly: I have no good idea how to solve this. :-)

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7208 (draft-ietf-spfbis-4408bis-21)
--------------------------------------
Title               : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
Publication Date    : April 2014
Author(s)           : S. Kitterman
Category            : PROPOSED STANDARD
Source              : SPF Update
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: "John R. Levine" <[email-masked]>
Date: 3 Jun 2021 11:43:21 -0400

The void lookup limit was a bad idea that has only gotten worse.  As 
nobody seemed to notice at the time, you get a different answer verifying 
IPv4 and IPv6 messages since a name with an A record may have no AAAA 
record.

I'm inclined to reject it, since the current language reflects the intent 
of the WG, even though in retrospect we should have done better.

> "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1".

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Stuart D. Gathman" <[email-masked]>
Date: Thu, 03 Jun 2021 11:59:03 -0400

On Thu, 2021-06-03 at 02:35 -0700, RFC Errata System wrote:
> .....
> In addition to the above suggestion, I still see a contradiction
> between the "void lookup limit" and the "exists" mechanism. The
> functionality of "exists" includes (in my opinion) the negative
> response (RCODE 3). But the "void lookup limit" allows this to occur
> only twice. This limits the use of "exists" very much.

Note that the specific case:

v=spf1 exists:%{ir}.list1.example.net exists:%{ir}.list2.example.net
exists:%{ir}.list3.example.net -all

is not a well designed used of "exists".  I claim that only one call to
"exists" is needed, which can include all the macros for information it
needs.  The authoritative server for the "exists" then has all info it
needs to render a verdict.  The "exists" mechanism is properly
understood as a remote proceedure call via DNS with arbitrary text
parameters and a boolean output.

The only reason (that I've seen) you would ever need more than one
"exists" is when trying to repurpose existing DNS blacklists or
whitelists.  And SPF policy is not the place to consult multiple such
lists.  Use Power DNS or whatever and make your own derivative list.

In fact, if your SPF policy is exceding limits, and you really need all
the convoluted logic - then I believe any policy can be delegated to a
single "exists" call passing all the needed info via macros in the
hostname labels.