Re: [dmarc-ietf] Ticket #1 - SPF alignment

Alessandro Vesely <> Wed, 27 January 2021 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 45D963A0CAF for <>; Wed, 27 Jan 2021 09:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Status: No, score=-2.121 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 LKN3hErEOLCi for <>; Wed, 27 Jan 2021 09:26:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C21F3A0CB1 for <>; Wed, 27 Jan 2021 09:26:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1611768361; bh=DTqHQOZmNVEgAgt4l8tuQuphNyOuHNTbN+Pea6hoklQ=; l=3899; h=To:References:From:Date:In-Reply-To; b=AYpG8pPe+1Chloq7gy4CZdXYwL1eeaAP8CNcnsXC2vd0c7UrwFeuXo1o0DAUr2LuM nfCfaoyk/Wf3AvQHaATqGpjwmCd+j3EurImtsA6K/6AMJpCvCDAv3WepRGPcOoVqci GlIzMgC6NUuSaHuEFGN4h41o86jA8Q1x2qKKJkValDPxktFTWhZLt6SKdSPAc
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 00000000005DC026.000000006011A229.000057DB; Wed, 27 Jan 2021 18:26:01 +0100
References: <> <1655426.E2olI3CrJK@zini-1880> <> <3776619.NdRDDhGtae@zini-1880>
From: Alessandro Vesely <>
Message-ID: <>
Date: Wed, 27 Jan 2021 18:25:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <3776619.NdRDDhGtae@zini-1880>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jan 2021 17:26:05 -0000

On Wed 27/Jan/2021 15:00:29 +0100 Scott Kitterman wrote:
> On Wednesday, January 27, 2021 4:49:02 AM EST Alessandro Vesely wrote:
>> On Tue 26/Jan/2021 23:36:19 +0100 Scott Kitterman wrote:
>>> On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote:
>>>> On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote:
>>>>> On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote:
>>>>>> I doubt that SPF filters report envelope-from=postmaster@HELO; more
>>>>>> likely they write helo=HELO.  In that case, the paragraph quoted above
>>>>>> is deceptive.
>>>>>>> I believe the proposed text is clear enough about not using
>>>>>>> separate HELO identity results and that's appropriate. >>>>
>>>>>> My filter collects SPF results recorded from an upstream SPF filter.
>>>>>> It writes Received-SPF: lines for each identity.  For NDNs, it writes
>>>>>> a Received-SPF: for the HELO identity only.  Am I allowed to use that
>>>>>> result for DMARC?
>>>>> No.  You should only use Mail From results.
>>>> So NDNs having only an aligned HELO will never pass DMARC?
>>>> And what is a <scope>helo</scope> element in aggregate reports provided
>>>> for?
>>>> The spec says:
>>>>           [SPF] can authenticate either the domain that appears in the
>>>>     RFC5321.MailFrom (MAIL FROM) portion of [SMTP] or the RFC5321.EHLO/
>>>>     HELO domain, or both.
>>>> And then:
>>>>     In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
>>>>     domain must have the same Organizational Domain.  In strict mode,
>>>>     only an exact DNS domain match is considered to produce Identifier
>>>>     Alignment.
>>>> So, consider the following message without DKIM signatures:
>>>> HELO
>>>> MAIL FROM:<>
>>>> Received-SPF: pass (domain
>>>>    designates as permitted sender)
>>>>    identity=helo;;
>>>> Received-SPF: fail (domain of
>>>>    denies as permitted sender)
>>>>    identity=mailfrom; envelope-from="".com";
>>>> Subject: Not using a mail client for this example
>>>> From:
>>>> Does it pass DMARC?
>>> No.
>> Let's not be silly, Scott.  We have as the SPF-authenticated 
>> domain and it is aligned with From:.  Are you saying that the message
>> would pass if it had an empty bounce address, but since it can bounce it
>> does not pass?!? >
> All I'm saying is that DMARC only uses mail from results and that's 
> appropriate.  I don't think the case of HELO name being aligned, but mail
> from domain is not is one to worry about.

That's abnormal, not appropriate.

AFAIUI, there's no reason why SPF would work with a logic substantially 
different than DKIM's.  DKIM can provide n identifiers, if one of them is 
aligned and "pass", then DMARC is "pass".  SPF can provide 2 identifiers but 
one of them is of class B.  WTF?

Can anyone explain why we have a <scope>helo</scope> element in aggregate reports?

Can we fix this aberration?

The spec needs a fix anyway, because from the text I quoted above I understood 
that the example message passes DMARC.  Am I the only one?

In addition, as I said, SPF filters are likely to report HELO as helo and MAIL 
FROM as mailfrom.  If we want to carry over this quirk, the spec must say that 
a DMARC filter which gathers SPF authentication status from an upstream filter 
MUST make sure that mailfrom is empty before validating based on an aligned helo.

Dropping that absurd discrimination between SPF identifiers would make for a 
smoother spec.  Since non-null mailfroms are in most cases aligned with either 
From: or helo, the differences between existing compliant implementations and 
the smoother spec would be limited to a hardly noticeable set of test messages.