From nobody Fri Nov 9 08:59:41 2018 Return-Path: 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 ; 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 ; 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 ; 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 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, 9 Nov 2018 08:59:20 -0800 (PST) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 or will have result "none" (and pass) but those that have HELO 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 From nobody Fri Nov 9 11:17:49 2018 Return-Path: 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 20C5C130DC4 for ; Fri, 9 Nov 2018 11:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=GCHf6frg; dkim=pass (2048-bit key) header.d=kitterman.com header.b=K5mxm3aP 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 X3dZaQN9GWOM for ; Fri, 9 Nov 2018 11:17:45 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18F6130DC0 for ; Fri, 9 Nov 2018 11:17:44 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541791062; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=Fy/V9INVCMu317hnukG45JPYXO5lSpzPf2o7VgFZjME=; b=GCHf6frg8umPDPejE0ARdKTRV5GCVZO/RuyrernHG2RWgKOhhHS+F4aA b7vPVEDwj1+I+2JEjD9hY1T9348TDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541791062; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=Fy/V9INVCMu317hnukG45JPYXO5lSpzPf2o7VgFZjME=; b=K5mxm3aPfelGfrft/8Bj0m4bJd5offzYDkirt81ux0B4IEwiXCcSSNgo NELRkZ6WLlnvteXbcZ7y6fJgO3YMo2gTI3P/lfAor0JuSIDPrYxodSr1g9 pPpiaNQOzOMkxYtbhNL0SS8hpJ/zNrbNFMO2LIWfSEWyZ6nUMhRugJ2v/J FjyOrLug/bjxZWjALYxOnRGD+PE8gBUritZLhDdIbulMaacCMPBFutfEEr v52KlMuaeB1yhengGkY4ijnDC32yGu5qrTqRIRkORttTnLDJ9Qws0WUfc1 JZAZqm8ix0Ig7ghx7ipoBecpgh8VPo0YjtE6KohmiF8Y/baOCHNtWw== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 131E8C40198; Fri, 9 Nov 2018 13:17:42 -0600 (CST) From: Scott Kitterman To: RFC Errata System Cc: ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, sm+ietf@elandsys.com, ajs@anvilwalrusden.com, dear.friend@2die4.com, spfbis@ietf.org Date: Fri, 09 Nov 2018 14:17:41 -0500 Message-ID: <2394369.44pl4s8oyQ@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20181109165920.AF8B2B810A6@rfc-editor.org> References: <20181109165920.AF8B2B810A6@rfc-editor.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [spfbis] [Technical Errata Reported] RFC7208 (5550) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 19:17:47 -0000 My recommendation is that the errata be rejected. Rationale: The submitter doesn't follow through what the next steps in the process would be and makes incorrect assumptions. As described in the errata, HELO/EHLO names that are HELO or will have a HELO check result of none. In the case of HELO , the claim that if does not have an A record, the HELO check result will be fail is incorrect. If the HELO is a valid hostname, then the first step would be do a DNS TXT lookup to determine if there is a valid SPF record. If there is no record, then the result is none, just like HELO or . If there is an SPF record for the HELO name and the record uses an a:/aaaa: mechanism for which no A/AAAA record exists, then the result will be whatever is specified based on the qualifier for the 'all' mechanism at the end of the record. This may or may not be fail. In the latter case, the unanticipated result is a function of an incorrect operational configuration, not an issue with the protocol. It is true that publishing an incorrect SPF record can have negative consequences, but that's true for all SPF records and nothing related to this text. Scott K On Friday, November 09, 2018 08:59:20 AM 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: > http://www.rfc-editor.org/errata/eid5550 > > -------------------------------------- > Type: Technical > Reported by: Borislav Petrov > > 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 or will have > result "none" (and pass) but those that have HELO 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 From SRS0=GDzSC=NU==stuart@gathman.org Fri Nov 9 11:35:49 2018 Return-Path: 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 48FF4129619 for ; Fri, 9 Nov 2018 11:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-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 5ZQYlguGKhm4 for ; Fri, 9 Nov 2018 11:35:48 -0800 (PST) Received: from mail.gathman.org (mail.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 D93A112008A for ; Fri, 9 Nov 2018 11:35:47 -0800 (PST) Authentication-Results: mail.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=1541792114; h=date : from : subject : to : cc : message-id : in-reply-to : references : mime-version : content-type : date : from : subject; bh=oa04+wTN5QEjCu7CA9If1oUjgAvvwpIwoEov18OOIeA=; b=E/quS4EgZLdOnIusYtCEZAOb3rffJ7/PnlIsQ1jvZC0arLDoTvYJ76qE 6m28T5vvz8BhigK6zVC6cs9R6uWqhpw5eRoFAXT+Fc8kwLCfS2P/E3BTGH OFfQQxyY9X9OjHR1Bk7XUOB4YFRIW9208Snok0gikfeoQLSHNXB5NckzQ= Received: from elissa.gathman.org ([IPv6:2001:470:8:809::109f]) (authenticated bits=0) by mail.gathman.org (8.14.7/8.14.7) with ESMTP id wA9JZDcB029839 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Nov 2018 14:35:14 -0500 Date: Fri, 09 Nov 2018 14:35:15 -0500 From: "Stuart D. Gathman" To: Scott Kitterman Cc: RFC Errata System , ben@nostrum.com, adam@nostrum.com, aamelnikov@fastmail.fm, sm+ietf@elandsys.com, ajs@anvilwalrusden.com, spfbis@ietf.org, dear.friend@2die4.com Message-Id: <1541792115.6280.1@mail.gathman.org> In-Reply-To: <2394369.44pl4s8oyQ@kitterma-e6430> References: <20181109165920.AF8B2B810A6@rfc-editor.org> <2394369.44pl4s8oyQ@kitterma-e6430> X-Mailer: geary/0.12.4 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-EzUCpuOV6qUfzHfGxez9" Archived-At: Subject: Re: [spfbis] [Technical Errata Reported] RFC7208 (5550) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 19:41:52 -0000 --=-EzUCpuOV6qUfzHfGxez9 Content-Type: text/plain; charset=us-ascii; format=flowed +1 Scott K stated it well. I was going to write something similar. I use an implicit default record of "v=spf1 a" for HELO, which also simply gives a neutral result in the case he is concerned about, On Fri, Nov 9, 2018 at 2:17 PM, Scott Kitterman wrote: > My recommendation is that the errata be rejected. > --=-EzUCpuOV6qUfzHfGxez9 Content-Type: text/html; charset=us-ascii

+1 Scott K stated it well. I was going to write something similar. I use an implicit default record of "v=spf1 a" for HELO, which also simply gives a neutral result in the case he is concerned about,

On Fri, Nov 9, 2018 at 2:17 PM, Scott Kitterman <scott@kitterman.com> wrote:

My recommendation is that the errata be rejected.

--=-EzUCpuOV6qUfzHfGxez9-- From nobody Mon Nov 12 11:06:59 2018 Return-Path: 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 D52C01274D0 for ; Mon, 12 Nov 2018 11:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=1TSkBsbA; dkim=pass (2048-bit key) header.d=kitterman.com header.b=ZtJFFzmd 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 CSEfSedFmTbF for ; Mon, 12 Nov 2018 11:06:55 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA154130E66 for ; Mon, 12 Nov 2018 11:06:55 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1542049613; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=OfeAfwy4+6umcqtPu/MslxziOK+nrTLGGa4HUFdAOGk=; b=1TSkBsbAPRRyU3bGXS82Iz3JtToVawSMim4cidNXYJ5Xf0aC6MY9epav oL+NiBNo7WOcWInpHvGklcidRjuxAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1542049613; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=OfeAfwy4+6umcqtPu/MslxziOK+nrTLGGa4HUFdAOGk=; b=ZtJFFzmdEYmdZFr6f6VnQaplJdC0wWdiuQYvIWzDvhj3CoRWs/zgJ5vH gas7w01Haf1H+gSzd4AuoMkaev3AR39KIumSk47Z1z2WIRlNAziMoo4/YF uvZMiIGX36ZPGuNo9E2YmHScR7BlOAfwJ7YFZm3YPJ+0ROElOs7VcCyMM2 +fRfjrT2bqlOTd/5d0jIWBhK1MbsBPji7MuHbuIbShCy73lq8xgxV8g6Ri mX22IMmtKLgdqCGPc7etCsLkLjJWdEvM+aNb+1/h3+5YN0HgCZac2Jlxj+ o2c5kLRtJIk6HNxJIS20hRnvsrSNd/NkZhkDP0eGCJbYG7l0B9HLuA== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 78C63C401AD; Mon, 12 Nov 2018 13:06:53 -0600 (CST) From: Scott Kitterman To: spfbis@ietf.org Cc: RFC Errata System , ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, sm+ietf@elandsys.com, ajs@anvilwalrusden.com, poccil14@gmail.com Date: Mon, 12 Nov 2018 14:06:51 -0500 Message-ID: <1976957.bQtEfv25dp@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20180723163232.9A308B81350@rfc-editor.org> References: <20180723163232.9A308B81350@rfc-editor.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [spfbis] [Technical Errata Reported] RFC7208 (5436) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 19:06:58 -0000 I think this errata should be accepted. Sorry for missing it when it came in. Scott K On Monday, July 23, 2018 09:32:32 AM 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: > http://www.rfc-editor.org/errata/eid5436 > > -------------------------------------- > Type: Technical > Reported by: Peter Occil > > Section: GLOBAL > > Original Text > ------------- > header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] > [ key-value-list ] CRLF > > Corrected Text > -------------- > header-field = "Received-SPF:" [CFWS] result [ FWS comment ] > [ FWS key-value-list ] [FWS] CRLF > > Notes > ----- > As specified, this ABNF doesn't allow a header field value like > result-FWS-comment with no FWS or key-value-list following it, a header > field value which occurs very often in Received-SPF header fields I see in > practice. (Note that FWS must contain at least one white space.) The > corrected ABNF better follows practice in implementations. > > 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 mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From nobody Mon Nov 12 11:10:15 2018 Return-Path: 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 B4A5F130E02 for ; Mon, 12 Nov 2018 11:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=fzfZE13H; dkim=pass (2048-bit key) header.d=kitterman.com header.b=Q/OTjK+q 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 poq5EPp39xSM for ; Mon, 12 Nov 2018 11:10:12 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85EE1274D0 for ; Mon, 12 Nov 2018 11:10:11 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1542049810; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=jp9fuNIx2FxrkX2omJJKpnmREMpuDSU7GEat5R9vig4=; b=fzfZE13HUYKFWUMOLUe5EC0Igh5LihWXYkRXJogNI4GN2Fd8Ey92M1s8 7igYodw4qelJPIWmgpvsEvrByisKDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1542049810; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type : from : subject : date; bh=jp9fuNIx2FxrkX2omJJKpnmREMpuDSU7GEat5R9vig4=; b=Q/OTjK+qF2vlscdzrrp02FmGbQp+SQNwLYr2xfauzzCOF6cwchENH3S/ PhChEIFxiMyTwIR7ToMUamufBydXVt+Pejb6Rtr0Mp4FxQhbRCsjwVEsDN ZeeX7UjC2SRDnUK8Qf6nWnPXMQlSuuA7njs5xzW5fhYcP79lxyczDAtTJU XGXWxIKTOfUmsh854Z8uOfLQA3loprJ5f8tZGh2wNvKat6agcAL+ZapNJ6 KdDgtjqHYC3qgkGi7aPLfIvq7+ckmxoEYwZBlUe/Ls48hNVjqP+pvvyaRf BUV6EHf+0b3FvTG8Gi+2LvoJ6zCnwXbVOWdhTU5lP0+LP8IR8gKPkQ== Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A19C7C401C4; Mon, 12 Nov 2018 13:10:10 -0600 (CST) From: Scott Kitterman To: spfbis@ietf.org Cc: RFC Errata System , ben@nostrum.com, adam@nostrum.com, aamelnikov@fastmail.fm, sm+ietf@elandsys.com, ajs@anvilwalrusden.com, dear.friend@2die4.com Date: Mon, 12 Nov 2018 14:10:08 -0500 Message-ID: <10227312.lQhgs7rMoL@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-158-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <2394369.44pl4s8oyQ@kitterma-e6430> References: <20181109165920.AF8B2B810A6@rfc-editor.org> <2394369.44pl4s8oyQ@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [spfbis] [Technical Errata Reported] RFC7208 (5550) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 19:10:14 -0000 After further off-line discussion with the reporter, my recommendation to reject this errata is confirmed in my mind. I think that most of his issue is with how various SPF results are used by receivers, which is out of scope of RFC 7208. It does not specify receiver policy. Scott K On Friday, November 09, 2018 02:17:41 PM Scott Kitterman wrote: > My recommendation is that the errata be rejected. > > Rationale: > > The submitter doesn't follow through what the next steps in the process > would be and makes incorrect assumptions. > > As described in the errata, > > HELO/EHLO names that are HELO or will have a HELO > check result of none. In the case of HELO , the claim that if > does not have an A record, the HELO check result will be fail is > incorrect. > > If the HELO is a valid hostname, then the first step would be do a DNS TXT > lookup to determine if there is a valid SPF record. If there is no record, > then the result is none, just like HELO or . > > If there is an SPF record for the HELO name and the record uses an a:/aaaa: > mechanism for which no A/AAAA record exists, then the result will be > whatever is specified based on the qualifier for the 'all' mechanism at the > end of the record. This may or may not be fail. > > In the latter case, the unanticipated result is a function of an incorrect > operational configuration, not an issue with the protocol. It is true that > publishing an incorrect SPF record can have negative consequences, but > that's true for all SPF records and nothing related to this text. > > Scott K > > On Friday, November 09, 2018 08:59:20 AM 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: > > http://www.rfc-editor.org/errata/eid5550 > > > > -------------------------------------- > > Type: Technical > > Reported by: Borislav Petrov > > > > 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 or will > > have result "none" (and pass) but those that have HELO 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 mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From nobody Mon Nov 26 10:23:55 2018 Return-Path: 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 ADC02130DDA; Mon, 26 Nov 2018 10:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yq3rUTSZtknB; Mon, 26 Nov 2018 10:23: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 6339F130DD3; Mon, 26 Nov 2018 10:23:43 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5F91BB80B65; Mon, 26 Nov 2018 10:23:43 -0800 (PST) To: poccil14@gmail.com, scott@kitterman.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aamelnikov@fastmail.fm, iesg@ietf.org, spfbis@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181126182343.5F91BB80B65@rfc-editor.org> Date: Mon, 26 Nov 2018 10:23:43 -0800 (PST) Archived-At: Subject: [spfbis] [Errata Verified] RFC7208 (5436) X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2018 18:23:45 -0000 The following errata report has been verified 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/eid5436 -------------------------------------- Status: Verified Type: Technical Reported by: Peter Occil Date Reported: 2018-07-23 Verified by: Alexey Melnikov (IESG) Section: GLOBAL Original Text ------------- header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF Corrected Text -------------- header-field = "Received-SPF:" [CFWS] result [ FWS comment ] [ FWS key-value-list ] [FWS] CRLF Notes ----- As specified, this ABNF doesn't allow a header field value like result-FWS-comment with no FWS or key-value-list following it, a header field value which occurs very often in Received-SPF header fields I see in practice. (Note that FWS must contain at least one white space.) The corrected ABNF better follows practice in implementations. -------------------------------------- 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