From nobody Thu Jan  4 11:18:46 2018
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 0782312D77D for <spfbis@ietfa.amsl.com>; Thu,  4 Jan 2018 11:18:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 H9UPm5LOf1Lf for <spfbis@ietfa.amsl.com>; Thu,  4 Jan 2018 11:18:43 -0800 (PST)
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 1193C126CD8 for <spfbis@ietf.org>; Thu,  4 Jan 2018 11:18:43 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 3ED49B81099; Thu,  4 Jan 2018 11:18:27 -0800 (PST)
To: scott@kitterman.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, sm+ietf@elandsys.com, ajs@anvilwalrusden.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: david@dev.barlinq.com, spfbis@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20180104191827.3ED49B81099@rfc-editor.org>
Date: Thu,  4 Jan 2018 11:18:27 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/MKfTFmK0Lsp_w_dWIxbfsD41KyQ>
Subject: [spfbis] [Technical Errata Reported] RFC7208 (5227)
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.22
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, 04 Jan 2018 19:18:45 -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:
http://www.rfc-editor.org/errata/eid5227

--------------------------------------
Type: Technical
Reported by: David Garfield <david@dev.barlinq.com>

Section: 5.5

Original Text
-------------
   The <ip>'s name is looked up using this procedure:

   o  Perform a DNS reverse-mapping for <ip>: Look up the corresponding
      PTR record in "in-addr.arpa." if the address is an IPv4 address
      and in "ip6.arpa." if it is an IPv6 address.

   o  For each record returned, validate the domain name by looking up
      its IP addresses.  To prevent DoS attacks, the PTR processing
      limits defined in Section 4.6.4 MUST be applied.  If they are
      exceeded, processing is terminated and the mechanism does not
      match.

   o  If <ip> is among the returned IP addresses, then that domain name
      is validated.

   Check all validated domain names to see if they either match the
   <target-name> domain or are a subdomain of the <target-name> domain.
   If any do, this mechanism matches.  If no validated domain name can
   be found, or if none of the validated domain names match or are a
   subdomain of the <target-name>, this mechanism fails to match.  If a
   DNS error occurs while doing the PTR RR lookup, then this mechanism
   fails to match.  If a DNS error occurs while doing an A RR lookup,
   then that domain name is skipped and the search continues.

   This mechanism matches if

   o  the <target-name> is a subdomain of a validated domain name, or

   o  the <target-name> and a validated domain name are the same.

   For example, "mail.example.com" is within the domain "example.com",
   but "mail.bad-example.com" is not.


Corrected Text
--------------
   The <ip>'s name is looked up using this procedure:

   o  Perform a DNS reverse-mapping for <ip>: Look up the corresponding
      PTR record in "in-addr.arpa." if the address is an IPv4 address
      and in "ip6.arpa." if it is an IPv6 address.

   Check all domain names to see if they either match the
   <target-name> domain or are a subdomain of the <target-name>
   domain.  If any do, this domain name can be validated.  If no
   domain name can be found, or if none of the domain names match or
   are a subdomain of the <target-name>, this mechanism fails to
   match.  If a DNS error occurs while doing the PTR RR lookup, then
   this mechanism fails to match.

   This mechanism may match if

   o  the <target-name> is a subdomain of a domain name, or

   o  the <target-name> and a domain name are the same.

   For example, "mail.example.com" is within the domain "example.com",
   but "mail.bad-example.com" is not.


   The domain names received must also be validated for the mechanism
   to match.

   o For each matched record, validate the domain name by looking up
      its IP addresses.  To prevent DoS attacks, the PTR processing
      limits defined in Section 4.6.4 MUST be applied.  If they are
      exceeded, processing is terminated and the mechanism does not
      match.

   o  If <ip> is among the returned IP addresses, then that domain name
      is validated.

   If a DNS error occurs while doing an A RR lookup, then that domain
   name is skipped and the search continues.


   The mechanism matches if a domain name is found that properly
   matches the target name and can be properly validated.  While these
   tests can be done in either order, performing the match before
   validating prevents needless DNS queries being performed.


Notes
-----
As specified, the RFC calls for all names to be validated, even those that can be immediately discarded because they do not match.   The RFC should call for the local-only operation to be done first.  While it may be argued that the RFC doesn't require the order, implementers shouldn't be misled.

My corrected text probably needs editorial work.

I have not fixed errata 4751 in my corrected text.

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 Jan  4 11:33:19 2018
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 EFA6E129C6B for <spfbis@ietfa.amsl.com>; Thu,  4 Jan 2018 11:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hXxJyHgLU69F for <spfbis@ietfa.amsl.com>; Thu,  4 Jan 2018 11:33:16 -0800 (PST)
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 414E0124E15 for <spfbis@ietf.org>; Thu,  4 Jan 2018 11:33:16 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 6B721B8113C; Thu,  4 Jan 2018 11:33:00 -0800 (PST)
To: scott@kitterman.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, sm+ietf@elandsys.com, ajs@anvilwalrusden.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: david@dev.barlinq.com, spfbis@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20180104193300.6B721B8113C@rfc-editor.org>
Date: Thu,  4 Jan 2018 11:33:00 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/CalpIW2HYvOjlVxApvSPHrvDndQ>
Subject: [spfbis] [Technical Errata Reported] RFC7208 (5228)
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.22
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, 04 Jan 2018 19:33:18 -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:
http://www.rfc-editor.org/errata/eid5228

--------------------------------------
Type: Technical
Reported by: David Garfield <david@dev.barlinq.com>

Section: 5.5

Original Text
-------------
   Note: This mechanism is slow, it is not as reliable as other
   mechanisms in cases of DNS errors, and it places a large burden on
   the .arpa name servers.  If used, proper PTR records have to be in
   place for the domain's hosts and the "ptr" mechanism SHOULD be one of
   the last mechanisms checked.  After many years of SPF deployment
   experience, it has been concluded that it is unnecessary and more
   reliable alternatives should be used instead.  It is, however, still
   in use as part of the SPF protocol, so compliant check_host()
   implementations MUST support it.


Corrected Text
--------------
   Note: This mechanism is not as reliable as other
   mechanisms in cases of DNS errors.
   If used, proper PTR records have to be in
   place for the domain's hosts and the "ptr" mechanism SHOULD be one of
   the last mechanisms checked.  After many years of SPF deployment
   experience, it has been concluded that it is unnecessary and more
   reliable alternatives should be used instead.  It is, however, still
   in use as part of the SPF protocol, so compliant check_host()
   implementations MUST support it.


Notes
-----
I have not reflowed the text so it can be more clear what I changed.

        This mechanism is slow

In fact, if all the DNS records are in place, Errata 5227 is accounted
for, and the single PTR query is discounted, this mechanism produces
no more additional DNS queries than mechanism "a".  I.e. it produces
one A (or AAAA) query.  It is not slow.

        it places a large burden on the .arpa name servers

In fact, it requires 1 PTR query, for however many ptr mechanisms are
in the SPF record.  Further, most mail servers already do this PTR
query, to report the information on the "Received" line.  Even if a
seperate daemon is used to the SPF check, the data should already be
in a local caching name server.

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