[spfbis] [Technical Errata Reported] RFC7208 (5550)
RFC Errata System <rfc-editor@rfc-editor.org> Fri, 09 November 2018 16:59 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 B835A12D4F0 for <spfbis@ietfa.amsl.com>; Fri, 9 Nov 2018 08:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 c90zlMC9cGir for <spfbis@ietfa.amsl.com>; Fri, 9 Nov 2018 08:59:38 -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 1B3E4128766 for <spfbis@ietf.org>; Fri, 9 Nov 2018 08:59:38 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id AF8B2B810A6; Fri, 9 Nov 2018 08:59:20 -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: dear.friend@2die4.com, spfbis@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20181109165920.AF8B2B810A6@rfc-editor.org>
Date: Fri, 09 Nov 2018 08:59:20 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/_LV75SuQnGqEnJCeHaocT_Rv9vY>
Subject: [spfbis] [Technical Errata Reported] RFC7208 (5550)
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: Fri, 09 Nov 2018 16:59:40 -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/eid5550 -------------------------------------- Type: Technical Reported by: Borislav Petrov <dear.friend@2die4.com> Section: 2.3. Original Text ------------- Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF verifiers have to be prepared for the identity to be an IP address literal (see [RFC5321], Section 4.1.3) or simply be malformed. This SPF check can only be performed when the "HELO" string is a valid, multi-label domain name. Corrected Text -------------- Notes ----- It looks like that those who have HELO <IP Address> or <malformed> will have result "none" (and pass) but those that have HELO <hostname> and have not yet published their hostname (A record) as allowed sender will get fail. This becomes a very common case for all messages which are DSNs. The whole idea that it is better to have your HELO malformed than a valid hostname which identifies the system is wrong. The point is to fight spam but you actually make it easier for spammers to just have the EHLO malformed and send with <> reverse-path rather than having some proper EHLO/HELO which is subject to other verifications like rDNS, etc. 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 (555… RFC Errata System
- Re: [spfbis] [Technical Errata Reported] RFC7208 … Scott Kitterman
- Re: [spfbis] [Technical Errata Reported] RFC7208 … Stuart D. Gathman
- Re: [spfbis] [Technical Errata Reported] RFC7208 … Scott Kitterman