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

Douglas Foster <dougfoster.emailstandards@gmail.com> Thu, 13 October 2022 00:05 UTC

Return-Path: <dougfoster.emailstandards@gmail.com>
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 6633BC1522A8 for <dmarc@ietfa.amsl.com>; Wed, 12 Oct 2022 17:05:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 cdE6QhR6_5O2 for <dmarc@ietfa.amsl.com>; Wed, 12 Oct 2022 17:05:51 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE45AC1522A6 for <dmarc@ietf.org>; Wed, 12 Oct 2022 17:05:51 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id bp15so89014lfb.13 for <dmarc@ietf.org>; Wed, 12 Oct 2022 17:05:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=X/MO4Aa4ag4pUcRaLrxx6a4GC5UreSubXp3/q6XQyG8=; b=He//LNagUJMlVe91tGxKRHhM1EktCx6WT3fePE0n3L/eLlsBN/O/aBGHZp3wwGH02M e+lhJQt/kctKAdLQ8kmYIcUorIRv0sf3xM5AGQ6551UE1RNlPZz5acLrn+KbDLmbOhjf 6a9rihiw8VIt1CuEym7HxntQi81bClH4KUw0suQpoTITEoHk/++goQqAkwPsRTt5Ejdq DeMzGPyUraGNU6FQKLp3w8i2gmvuMo38TW5F+yi8GNXdfbXv2k5NiLa2QYALBc9JRScy DK9jJLf4NRGkv/dZppazWEDXJ7ZAM518Y0g61iGqhUuLXJWzn7QoVcz/eqKU6rLDcfK1 N1dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=X/MO4Aa4ag4pUcRaLrxx6a4GC5UreSubXp3/q6XQyG8=; b=zPauSl9855SZfi/gkR/dCyfV+qsZcLs9rEYS6Ej5htmiTSlz/HwXIs6UXoITyLi8gj 6ekoVoZPCJrgHnGAK5OI/f+XT2aq0fgIuLwNHoY4XCWkHBBkJBfMjXU+t4/PcjpDXTY/ NEr0mMkKyxr1u1Q3kMSM7IwhT092PlP347RzFopJ/YGOCD3P6GWd79o7GeG4/EyrLxgL z3aFTjIzuSQwkURLm1PPqKQSgYywiprwEC0nwnkmjX8vSyaM3rPxhqoufgmUnx1c86HI 8kv2NYguRsTqLaxe/fj/pgZxq25u4OmuiSEzbhyz8yn0ZgL/MU+l/pm2a/BSCY/kMNjA 7qYw==
X-Gm-Message-State: ACrzQf046rzyL4U8SfbZ2eGYIKpp4BAKIHeJXpCqcQuCN+bFhEX5BIK+ A8BgTmluChhxDICdITSAgmjRcO3x34B7/PEDb04XivS4
X-Google-Smtp-Source: AMsMyM4uoVJ57W1kF1IUXmN+3gHVty37QXnXcMTtfZ6QjSPGBQkyY5YAfyoFnmYmWjWWVqbeqC2YQzsJVXcI2aJQ+Yk=
X-Received: by 2002:ac2:5611:0:b0:4a2:7d0d:bf7a with SMTP id v17-20020ac25611000000b004a27d0dbf7amr10402203lfd.60.1665619548947; Wed, 12 Oct 2022 17:05:48 -0700 (PDT)
MIME-Version: 1.0
References: <165046214335.10055.16398898629460366752@ietfa.amsl.com> <CAH48ZfxZOq68=P-Qxjvjk1c8PxWAWDvaBPPQcb4DWmd6cL=u4Q@mail.gmail.com> <CAJ4XoYen6n06L1UBqzu9nr2jCC7v_-GOAdJXMzCks6d-AaKqUA@mail.gmail.com> <CAH48ZfzVt=+yoj280VxL_SV+YM4C7eqMWhL=41YpVybaPmLcLg@mail.gmail.com> <CAHej_8mgKjpo6DDbOS9bBdTarThKOa9F55QBtrM6G-oq1YfX+w@mail.gmail.com> <CAL0qLwYjYY4OvShqACWPz0vdJcAubdU1csFFVSkqzsReZSZxuw@mail.gmail.com> <MN2PR11MB43514940B87730CC9D476AACF75B9@MN2PR11MB4351.namprd11.prod.outlook.com> <CAL0qLwb=1CZN6s2QzWJGFeO3=iPWZ-eS=7hvi4B6jhuh+hLJ0w@mail.gmail.com> <8ab0943b-9805-1a0e-528d-9cf45f2eaf9c@tana.it> <CAH48ZfzM2J0_RizqESbFSm3ASfc2x6nsdxUXWEWO+4g2vXsz+g@mail.gmail.com> <38BC22D3-3A29-47E0-9E51-DD862FDD4947@wordtothewise.com> <CAH48ZfysLqgxi1mTjxEMVgSqgmj8J2=2coC0FRaHLQsJx2yQKQ@mail.gmail.com> <CAL0qLwZD_44t4w5jkObVn6sDyEiwh7EdNazqeUiZtA7VCJ+5MQ@mail.gmail.com>
In-Reply-To: <CAL0qLwZD_44t4w5jkObVn6sDyEiwh7EdNazqeUiZtA7VCJ+5MQ@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Wed, 12 Oct 2022 20:05:39 -0400
Message-ID: <CAH48ZfxENV10Q4njfL1ZNzK0G4WG3Dpd4Cdz7i5d7yiEZ_eOJA@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008bcaa305eadf4578"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/mnIsMm4uHnkr6xr5rzNvwe4lC6Q>
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: Thu, 13 Oct 2022 00:05:52 -0000

These examples seem to need their own result code.   The domain owner will
want to know that the signature was intact even though it was rejected,
because that tells him something important about the message flow.  But he
will also want to know that the signature, and possibly the message, was
rejected because of insufficient trust.

Pass, Fail, Unacceptable?

Doug

On Wed, Oct 12, 2022 at 12:39 AM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> On Mon, Oct 10, 2022 at 6:56 PM Douglas Foster <
> dougfoster.emailstandards@gmail.com> wrote:
>
>> Signatures not Evaluated
>> ----------------------------------
>> Based on the above, a message may have signatures which lack reported
>> results for any of these reasons:
>> - The verifier evaluated signatures until its hard limit on the number of
>> signatures was reached, then stopped.
>> - The verifier evaluated more signatures than the reporting specification
>> allows, so it could not report all of them.
>> - The verifier evaluated only those signatures needed to obtain a PASS
>> result, then stopped evaluating.
>>
>
> Also:
>
> - The verifier did not evaluate signature(s) that were disqualified due to
> matters of local policy.
>
> Some examples we've discussed before, which a verifier might insist before
> considering a signature to be valid (RFC 8601 uses the term "acceptable to
> the verifier"):
>
> - the Subject field was not included in the signature (it's a displayed
> field, and so shouldn't be meaningfully altered)
> - the "l=" tag was present (it has known security issues)
> - the hash or signing algorithm used is considered obsolete or insecure
> - the signing key had too few bits of entropy
>
> All but the last one can be checked without going to the DNS or doing any
> crypto-type work, and the signature can be skipped if the verifier's local
> requirements are not met.
>
> -MSK
>
>