From nobody Thu Jun  3 02:36:02 2021
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD0C3A31B5 for <spfbis@ietfa.amsl.com>; Thu,  3 Jun 2021 02:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH2ep2_qYREh for <spfbis@ietfa.amsl.com>; Thu,  3 Jun 2021 02:35:56 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7E83A31AE for <spfbis@ietf.org>; Thu,  3 Jun 2021 02:35:56 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 2A15FF4071F; Thu,  3 Jun 2021 02:35:33 -0700 (PDT)
To: scott@kitterman.com, superuser@gmail.com, francesca.palombini@ericsson.com, sm+ietf@elandsys.com, ajs@anvilwalrusden.com
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: chaosben@gmail.com, spfbis@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20210603093533.2A15FF4071F@rfc-editor.org>
Date: Thu,  3 Jun 2021 02:35:33 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/gzw2n5k-7hS3rQF2Agh8zJUcgPA>
Subject: [spfbis] [Technical Errata Reported] RFC7208 (6595)
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 09:36:01 -0000

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 <chaosben@gmail.com>

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 nobody Thu Jun  3 08:43:34 2021
Return-Path: <johnl@iecc.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601D93A003F for <spfbis@ietfa.amsl.com>; Thu,  3 Jun 2021 08:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFY-u_u3Kqzk for <spfbis@ietfa.amsl.com>; Thu,  3 Jun 2021 08:43:25 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C963A006A for <spfbis@ietf.org>; Thu,  3 Jun 2021 08:43:25 -0700 (PDT)
Received: (qmail 37609 invoked from network); 3 Jun 2021 15:43:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=92e7.60b8f89c.k2106; bh=gFlv+jtvHD+gwE3Ekl8ac4HiEokBDduLC1OArvTw7tM=; b=swPGbdq1JB0x3E/0oqeg5ijlO3+vOxFVpHQJf9RE6iZF1ngtPV0FjjvA7at+zIILwDorOh+R5ZLxu5F/7bha89VO1wJTHVzLPCExWAcDnIUVQUqNY1j+SEbI85uXFMj2lTG+LKF5AEz+RfqbG8hTZKq1rJFNKfetqE4mS4D7VE1Ajv93f2w8i1viv042QwA0H6jeyBHUEhs2gGqgzl4gYlv5l69iljIG5WsND4sfGZIYykX6i2VT+g+LDqRhT+Ml7gvLdAaTXQYhTWL5J8V8L5NkHmeux+OzQ64LRhgPt24P9Zj2ry8mzME7JQapwYGveaanqeGxOpdip0ZFhDRxOA==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 03 Jun 2021 15:43:23 -0000
Received: by ary.qy (Postfix, from userid 501) id 474E1B2BD0F; Thu,  3 Jun 2021 11:43:22 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 0EDC6B2BCE1; Thu,  3 Jun 2021 11:43:22 -0400 (EDT)
Date: 3 Jun 2021 11:43:21 -0400
Message-ID: <65cc1e0-83a-a8c2-a26c-2ca522f89d5c@iecc.com>
From: "John R. Levine" <johnl@iecc.com>
To: "RFC Errata System" <rfc-editor@rfc-editor.org>, scott@kitterman.com, superuser@gmail.com, francesca.palombini@ericsson.com, sm+ietf@elandsys.com, ajs@anvilwalrusden.com
Cc: spfbis@ietf.org, chaosben@gmail.com
X-X-Sender: johnl@ary.qy
In-Reply-To: <20210603093533.2A15FF4071F@rfc-editor.org>
References: <20210603093533.2A15FF4071F@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/ZfAJIPuZxHnXVRRrex04jV2B9rI>
Subject: Re: [spfbis] [Technical Errata Reported] RFC7208 (6595)
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 15:43:33 -0000

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.


On Thu, 3 Jun 2021, RFC Errata System wrote:

> 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 <chaosben@gmail.com>
>
> 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
>

Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


From SRS0=5k5qA=K5==stuart@gathman.org  Thu Jun  3 08:59:44 2021
Return-Path: <SRS0=5k5qA=K5==stuart@gathman.org>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866903A07C3 for <spfbis@ietfa.amsl.com>; Thu,  3 Jun 2021 08:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gathman.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoUn0JFwcUHA for <spfbis@ietfa.amsl.com>; Thu,  3 Jun 2021 08:59:40 -0700 (PDT)
Received: from mail.gathman.org (wiki.gathman.org [IPv6:2001:470:8:809::1010]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D171D3A07C0 for <spfbis@ietf.org>; Thu,  3 Jun 2021 08:59:39 -0700 (PDT)
Authentication-Results: mail.gathman.org; iprev=pass policy.iprev="2001:470:8:809::38" (melissa.gathman.org); auth=pass (PLAIN sslbits=256) smtp.auth=stuart
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gathman.org;  i=@gathman.org; q=dns/txt; s=default; t=1622735936;  h=message-id : subject : from : to : cc : date :  in-reply-to : references : content-type : mime-version :  content-transfer-encoding : subject : from : date;  bh=fgK8+XTHbMHsEk+oyJiKpYW9KqPr1zT7tvRXFteWaF0=;  b=QsVzupBcPbjKv6Ap5zT1wVpmhHXcbPMj8QUXU++/bQTBdwpEWIPBf47b xjZHw2Me7Ir1tCNZZiuwbfLvDkW2bBrgOaGtCsRVapGJIqXNex51J/9zKs pK3/+DUFhcssOvVp0GSrz4NGyiDsCYXygiP04b98N4UCBoLQ2BsCZblUs=
Received: from melissa.gathman.org (melissa.gathman.org [IPv6:2001:470:8:809::38]) (authenticated bits=0) by mail.gathman.org (8.14.7/8.14.7) with ESMTP id 153FwsBY023983 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jun 2021 11:58:55 -0400
Message-ID: <de54d3ee1747345a9871a0d20f841ee3da61bda3.camel@gathman.org>
From: "Stuart D. Gathman" <stuart@gathman.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>, scott@kitterman.com, superuser@gmail.com, francesca.palombini@ericsson.com, sm+ietf@elandsys.com, ajs@anvilwalrusden.com
Cc: spfbis@ietf.org, chaosben@gmail.com
Date: Thu, 03 Jun 2021 11:59:03 -0400
In-Reply-To: <20210603093533.2A15FF4071F@rfc-editor.org>
References: <20210603093533.2A15FF4071F@rfc-editor.org>
Organization: Gathman Family
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/ocQUweI_JTrRG9XVhgThAmNfK64>
Subject: Re: [spfbis] [Technical Errata Reported] RFC7208 (6595)
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 16:00:40 -0000

On Thu, 2021-06-03 at 02:35 -0700, RFC Errata System wrote:
> 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
> .....
> 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.