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

Alessandro Vesely <vesely@tana.it> Tue, 26 January 2021 16:47 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188293A0A63 for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 08:47:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.221
X-Spam-Level:
X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[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: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 gyY_-Qlzo-0f for <dmarc@ietfa.amsl.com>; Tue, 26 Jan 2021 08:47:55 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 24FAB3A0A4C for <dmarc@ietf.org>; Tue, 26 Jan 2021 08:47:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611679672; bh=liNs2TtN2Aod49sRH9uuXPCrnYQ7wZITOMvl5eneQ0w=; l=2682; h=To:References:From:Date:In-Reply-To; b=Bg+FvQ85UhSmVt+SqRhMv4Dxsl95szOMF4YxNSePCkGsPmRvaVR6tUIvOe6jLkNvy sLeSAWGNml1rb1vh3qhEc10FQ970xOsXCioAJz20nCgs9k9Vr67ixlzGHG8/9ki6P0 Hh+IJPL8AaUig8BtBFbtvf1+0F9wmzOnr2U60eGlEk8ZqUumQ15j7ILOgWNyj
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC028.00000000601047B8.00006497; Tue, 26 Jan 2021 17:47:52 +0100
To: dmarc@ietf.org
References: <bef64e7a-571b-a73f-dc91-aa402ca320c8@taugh.com> <1627293.fjaifilARp@zini-1880> <4563d5ac-f481-5af2-100d-4338f67c6da5@tana.it> <1859075.lZWC7Mh21l@zini-1880>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <3ed1bd47-43e9-3260-b2fe-567c967eede2@tana.it>
Date: Tue, 26 Jan 2021 17:47:51 +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: <1859075.lZWC7Mh21l@zini-1880>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/pGx2xFxks5LJGy8avUhpeIsSJiQ>
Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2021 16:47:57 -0000

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:
>> On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote:
>>> On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote:
>>>> May I propose that the section labeled "SPF-Authenticated Identifiers" be
>>>> rewritten as follows:
>>>> 
>>>> [...]
>>>> 
>>>>    The reader should note that SPF alignment checks in DMARC rely solely
>>>>    on the RFC5321.MailFrom domain. This differs from section 2.3 of
>>>>    [@!RFC7208], which recommends that SPF checks be done on not only the
>>>>    "MAIL FROM" but also on a separate check of the "HELO" identity. >
>>> 
>>> I think this is fine, but there is a subtlety to be aware of.
>>> 
>>> If you look at RFC 7208 Section 2.4, when Mail From is null,
>>> postmaster@HELO is the mail from for SPF purposes.  DMARC really can't
>>> change that.
>>> 
>>> As a result, there are cases where Mail From results actually are derived
>>> from HELO and it's unavoidable.
>> 
>> 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 example.org
MAIL FROM:<user@example.com>

Received-SPF: pass (domain example.org
   designates 192.0.2.1 as permitted sender)
   identity=helo; helo=example.org;
Received-SPF: fail (domain of user@example.com
   denies 192.0.2.1 as permitted sender)
   identity=mailfrom; envelope-from="user@example.com".com";
Subject: Not using a mail client for this example
From: different-user@example.org

Does it pass DMARC?

Best
Ale
--