Re: [spfbis] [Technical Errata Reported] RFC7208 (5550)

Scott Kitterman <> Fri, 09 November 2018 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20C5C130DC4 for <>; Fri, 9 Nov 2018 11:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=GCHf6frg; dkim=pass (2048-bit key) header.b=K5mxm3aP
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X3dZaQN9GWOM for <>; Fri, 9 Nov 2018 11:17:45 -0800 (PST)
Received: from ( [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (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;;; 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;;; 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 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 131E8C40198; Fri, 9 Nov 2018 13:17:42 -0600 (CST)
From: Scott Kitterman <>
To: RFC Errata System <>
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: <>
References: <>
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-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.


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 <IP Address> or <malformed> will have a HELO 
check result of none.  In the case of HELO <hostname>, the claim that if 
<hostname> does not have an A record, the HELO check result will be fail is 

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 <IP Address> or <malformed>.

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:
> --------------------------------------
> 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 <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