[spfbis] [Technical Errata Reported] RFC7208 (5228)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 04 January 2018 19:33 UTC

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