Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

Alessandro Vesely <vesely@tana.it> Fri, 21 October 2022 08:11 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 9FCC5C14F74F for <dmarc@ietfa.amsl.com>; Fri, 21 Oct 2022 01:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=AX5IBHfy; dkim=pass (1152-bit key) header.d=tana.it header.b=ArkV0fxm
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO5VDyTq9nOH for <dmarc@ietfa.amsl.com>; Fri, 21 Oct 2022 01:11:31 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E27C1522B4 for <dmarc@ietf.org>; Fri, 21 Oct 2022 01:11:27 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1666339880; bh=j0d2UxFgCsKOprzvmWoP0sQ166TUVHq/QmWTP4BQvIA=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=AX5IBHfyjU+Q2NUcgeGG/kquMUT5EwTYh/MIImDphs0Spmo7mM3mspvwoxb3dwloj mYwM9kwAvvTA6mGwgQtCg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1666339880; bh=j0d2UxFgCsKOprzvmWoP0sQ166TUVHq/QmWTP4BQvIA=; h=Date:Subject:To:References:From:In-Reply-To; b=ArkV0fxm2M8GydN/TfrsRCD2jHBaCo7Jw1pRPIyH+y15xh0e+RQC/uB1bCLPDhTe6 c+QTDCKF6NRWdKeApvgEQZ9miRQKYotfvzSV9H7TT/BcIA3cG/ojetEKTdv0icr9ub tcwvkcUwQr5ybJNN2aVAoxh+p0As9CVrjGEHL3yd+Y7SyH+TY6YS3Edx1baPO
Original-Subject: Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result
Author: 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 00000000005DC076.0000000063525428.0000474D; Fri, 21 Oct 2022 10:11:20 +0200
Message-ID: <f0d90ca7-38b7-3a1d-2be9-30cad7bec31c@tana.it>
Date: Fri, 21 Oct 2022 10:11:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0
Content-Language: en-US
To: dmarc@ietf.org
References: <9D6D6E80-B0B0-4CAD-B301-B0A17F9C6663@marmot-tech.com> <04FF4BB2-F8F3-4610-B33E-D4004C757E3B@marmot-tech.com> <CAH48Zfx+JPeoaFA4Z2zw982-+BkJcReyjK07u8w69KMSWx8vYQ@mail.gmail.com> <MN2PR11MB4351C32D2621D2024B39802BF72A9@MN2PR11MB4351.namprd11.prod.outlook.com> <CAH48Zfx0B5nvz9B2WJ-uUEeszyaoHbPoc1oubmjnrqo_H3x3Sw@mail.gmail.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <CAH48Zfx0B5nvz9B2WJ-uUEeszyaoHbPoc1oubmjnrqo_H3x3Sw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/_mOF-gsNnrZaWDyKWFkHufT-mUI>
Subject: Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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, 21 Oct 2022 08:11:38 -0000

On Fri 21/Oct/2022 00:53:56 +0200 Douglas Foster wrote:
> 
> Aligned DKIM PASS
> When an aligned DKIM result is PASS, I don't see that the domain owner needs 
> any more data collection performed.   The verifiable DKIM scope ID should tell 
> him where the message originated, and the source IP and HELO name tell the last 
> place it landed before delivery.    I cannot see why a domain owner would spend 
> a lot of time trying to analyze success results, unless his interests have 
> transitioned from assuring identity to analyzing marketing impacts.   We are 
> not trying to provide marketing data, and any successful use of DMARC for that 
> purpose seems like an encroachment on the privacy concerns that we want to 
> minimize.


Non-aligned signatures can be meaningful for various reasons.  In that case, 
the result of their evaluation is also meaningful.  For an example, the 
original author's domain signature, before From: was munged, is meaningful.  If 
it fails, it can be retried after undoing MLM transformation, possibly leading 
to secure recognition of the true author.  Is that worth its carbon footprint?

And for scope, one may wonder whether the recognized, or failed to be securely 
recognized original author's domain deserves a copy of the report.  People 
prone to set p=quarantine; pct=0 in order to avoid receiving "errors" would 
clearly dislike a copy of the report.  Others may want it, in order to tune 
their DKIM signing configuration.


> Duplicates:
> If an aligned domain has multiple DKIM signatures and one passes, I suggest 
> that the PASS is the only one that needs to be reported.  If an aligned domain 
> has multiple DKIM signatures and none pass, I suggest that the first one found 
> (from the top) is the most important, because it is the last one applied.   If 
> duplicates are reported, disaggregation is increased, so why report data that 
> is not useful?


Currently, putting 2 signatures, one rsa and one ed25519, is the way to monitor 
who supports the latter.


Best
Ale
--