[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, 04 Jan 2018 11:33:00 -0800
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
- [spfbis] [Technical Errata Reported] RFC7208 (522… RFC Errata System
- Re: [spfbis] [Technical Errata Reported] RFC7208 … S Moonesamy