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

Alessandro Vesely <vesely@tana.it> Fri, 29 January 2021 11:03 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 443363A0ADA for <dmarc@ietfa.amsl.com>; Fri, 29 Jan 2021 03:03:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
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: 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 CLxjQepPa--P for <dmarc@ietfa.amsl.com>; Fri, 29 Jan 2021 03:03:00 -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 948243A0AD6 for <dmarc@ietf.org>; Fri, 29 Jan 2021 03:03:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611918176; bh=+5yJh4z+zsMeKC1ZHok4S3EbXasJnaNjkY+/PEwOhqA=; l=2460; h=To:References:From:Date:In-Reply-To; b=CXSNio3p6Vt5+ibMTg+BE3r0FxmbYFA/xHH1Nxy35oVGAdg1hmL6NE1NSKvsPDXmi 1RGpZzM2+eXATemobrQy+7jOLQB7b1tSWK0gkESzrLEcZ/AdpzQ54Cw5367P2erdfC bw6K0zulSJSlL29xFeOfjJYQSOLf7WGt7+uz1PzP4Qx1pal0bkCAiOzY24WcK
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 00000000005DC026.000000006013EB5F.00003F1C; Fri, 29 Jan 2021 12:02:55 +0100
To: "Murray S. Kucherawy" <superuser@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
References: <bef64e7a-571b-a73f-dc91-aa402ca320c8@taugh.com> <1655426.E2olI3CrJK@zini-1880> <c39916f8-33f5-9876-c018-53085f5cc8f5@tana.it> <3776619.NdRDDhGtae@zini-1880> <81ab38a1-4b0a-3845-fc8c-7d49d7850c26@tana.it> <CAL0qLwZgB4iVSudbJeh8NGiKd1232SBTy4YDG6Zj-=LV+1m6Uw@mail.gmail.com> <fc735412-dfa2-20c8-087f-727b13eb3ad5@tana.it> <CAL0qLwbYxTXXXpx11L3f1CqBns=fSRho3C+S7q=-DmiPSvxKvg@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <cf51d6d4-0c7b-971d-bcac-743370f16433@tana.it>
Date: Fri, 29 Jan 2021 12:02:55 +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: <CAL0qLwbYxTXXXpx11L3f1CqBns=fSRho3C+S7q=-DmiPSvxKvg@mail.gmail.com>
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/vaxAF1uWuIc4_M2O0mBczgpUMgU>
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: Fri, 29 Jan 2021 11:03:02 -0000

On Thu 28/Jan/2021 21:40:49 +0100 Murray S. Kucherawy wrote:
> On Thu, Jan 28, 2021 at 4:13 AM Alessandro Vesely <vesely@tana.it> wrote:
> 
>>> DKIM (in its simplest form) returns N tuples of the form (d= domain, 
>>> pass/fail).  All of them were run through exactly the same check; all
>>> of them were attached to the message in exactly the same way; all of
>>> them have essentially identical semantics.  Giving them equal footing
>>> makes sense to me. >>>
>>> The two identifiers in SPF hold different places in the SMTP session,
>>> and have different semantics.  I think treating them differently is also
>>> just fine. >>
>> It is relevant that both identifier come from /the same/ SMTP session. 
>> That's not true for many DKIM signatures. >
> I guess if report consumers really want this information, we can include
> it.


Helo is essential if mfrom is missing.  A second SPF identifier is optional anyway.


> I just don't see the value in the HELO parameter if it's effectively
> random junk in the session.


Where does that notion come from?  Most mail admins choose the helo name 
carefully, possibly so that it resolves both ways to the IP number.

I just run a quick test on my current folder.  Out of 3879 messages I extracted 
944 unique helo names.  721 of these matched the reverse lookup exactly.  Out 
of the 223 remaining, 127 had an SPF pass for the helo identity anyway.  So in 
96 cases, roughly 10%, the helo name was indeed junk.  Isn't the remaining ~90% 
something worth considering?


> At least a passing DKIM signature is associated with a domain that existed
> at some point in time and whose DNS contained apparently-valid public keys.

Why cannot one type DKIM-Signature: d=anyrandomjunk ...?


> I can mostly type anything I want to HELO or EHLO.


That's true for any identifier.  We know an identifier is associated with a 
domain that existed at some point in time only after it's been authenticated.

One may say DKIM authentication is somewhat more precise, because the vogue is 
to include whole classes of IPs in SPF records.  But then, such lack of 
accuracy affects mfrom and helo alike.

The real difference between helo and mfrom is that the former is a 
configuration parameter of the sending relay, while the latter is set by the 
submission client.  The former is akin to d= and s=, while the latter is akin 
to From:.  No rationale to discard either, AFAICS.


Best
Ale
--