Re: [ietf-smtp] RFC 8601, clarification needed

Alessandro Vesely <> Mon, 24 May 2021 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2572E3A2F43 for <>; Mon, 24 May 2021 10:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dXEE-TwQy38j for <>; Mon, 24 May 2021 10:01:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FE333A2F40 for <>; Mon, 24 May 2021 10:01:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1621875660; bh=yGjJ+FV6Pha98i7+LACylWxTLoJ4lF3xAFt8nQI7bZU=; l=2530; h=To:References:From:Date:In-Reply-To; b=DD726iDssE24J6S4ntuRUM7QuOQGzfyF6lb1WWN3TIIeL7YGRGuavL3RyLxV48P9o ENzUMobpwub5CvjWa4jKmX5aqnNeaaUNn+MoQ1Dja7pfZC5DsaDocKaZ7H72BKKZ70 3msGCS7LN4RgyRmzkcuj2lTXpPpaRa0ieH8iOVjf6Yq6ceDdQQJMJjEBogILt
Authentication-Results:; auth=pass (details omitted)
Original-From: Alessandro Vesely <>
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by with ESMTPSA id 00000000005DC03D.0000000060ABDBCC.000020D5; Mon, 24 May 2021 19:01:00 +0200
References: <20210523175356.0B467881639@ary.qy>
From: Alessandro Vesely <>
Message-ID: <>
Date: Mon, 24 May 2021 19:01:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <20210523175356.0B467881639@ary.qy>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [ietf-smtp] RFC 8601, clarification needed
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 May 2021 17:01:10 -0000

On Sun 23/May/2021 19:53:54 +0200 John Levine wrote:
> It appears that David Bürgin <> said:
>> Authentication-Results:; spf=pass
>> Authentication-Results:; spf=pass
> That is wrong.  One A-R per pass through the MTA, please.

It's one A-R per agent, actually.  If the results were obtained by different 
agents they wouldn't step on each other's header fields.

>> Authentication-Results:;
>>  spf=pass;
>>  spf=pass
> You can do that if you want.

Right.  The following field, albeit syntactically correct, is excluded by the 
spec, which says «For SPF, the ptype used is "smtp", and the property is 
*either* "mailfrom" *or* "helo"» (my emphasis):


>> A subsequent component could then use these results as input to some
>> spam score, for example.
> You could, although in practice the HELO check doesn't tell you anything useful
> except when it's used as a fallback due to a null MAIL FROM.  The useful HELO
> check is to see if it exists at all, with a nonexistent one being a close to 100%
> accurate spam signal.  But if it doesn't exist, there is no SPF record so SPF
> tells you nothing.

Those are two different ways to configure a host as a mail outlet.  Receivers 
that check the DNS entry often require the reverse to match, which RFC 8601 
calls iprev, a.k.a. forward-confirmed reverse DNS (FCrDNS).  Setting up SPF 
HELO is easier, as repeating the IP address in a TXT RR in the same zone would 
suffice; that is, for example: IN A IN TXT "v=spf1 +ip4: -all"

However, many mail receivers hold the belief that the HELO argument can be 
gamed more than other identifiers.  That misconception presumably originates 
from a wrong interpretation of RFC 5321 saying «However, if the verification 
fails, the server MUST NOT refuse to accept a message on that basis.» 
Considering HELO a second class identifier is incarnated in DMARC («Note that 
the RFC5321.HELO identity is not typically used in the context of DMARC»). 
Then, because some DMARC implementations which consume A-Rs are unable to 
consider multiple SPF results, many A-R producers limit themselves to reporting 
the smtp.mailfrom only.