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

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 03 October 2022 14:03 UTC

Return-Path: <superuser@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 69751C1522D0 for <dmarc@ietfa.amsl.com>; Mon, 3 Oct 2022 07:03:51 -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=unavailable 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 ZO_Y74trhWLo for <dmarc@ietfa.amsl.com>; Mon, 3 Oct 2022 07:03:50 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 2608AC1524AE for <dmarc@ietf.org>; Mon, 3 Oct 2022 07:03:02 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id bj12so22334623ejb.13 for <dmarc@ietf.org>; Mon, 03 Oct 2022 07:03:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=TJdthrvHD92VJpNayGbovC1tzkwN/gyDhezH6DbgWP8=; b=Y1S2EsAXwOzdevGxh27SVQ4bdtWBuW3vRyOKmuTe8T/J5YxI9oxbGVJy2jeHksk532 7gW+y04kM3OmQmCfn8RVA+JKTK/ND9T6jkmDR4CPEUnlnS1f/7G5MY6DSK6lHTHriVOJ l0NAWwdML6DY3WHhPJ1vdjXruqH28Aij6pT3gGYo3WjorFDfC9qMsfcYYP7G7Nx5Mgwr 5dnVV29u84J4OvctkcUsPRB7OzPc+BPMvNtpbekvZ5gGeWSMYADpsfZEEf0Xu/LanMKm yIikf+B6ueRVTTdQw+Ev0PnRF0lPnI6n6MyymOowzm0bQ9C4yEM/xW1XgaYs1U0bDKoy stYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=TJdthrvHD92VJpNayGbovC1tzkwN/gyDhezH6DbgWP8=; b=iQACSzMUPz5GQqXJ+8WJQmJCXexlOBMN9Acg91q6ktisABIIJqfh8XKOR0xwTyV6vS URls3Mb/NjTNVJeTe/dg1y7uu90KqNsaXy+56o7IbkacCeHRhaoyhVB7SmOVW1IzSqG7 iCZjrSlijOxqAeO3f275gm+dvLmSmILw4/nNlLWDOWbo9j4QqGFp+885/PuhYu1W6Eto pFRJEZSkEjiaeQC4ygXJcDIAjcczAGRJUgstzbyk6JH0y47iboZVmFJGiZimX/KoftOX gjvexyHWGqJ9zMlWOXe8yd6uHVLq9FYYnHcaEjLcYrTxh6MApcrMhPqL198K54nm8JIZ +WsQ==
X-Gm-Message-State: ACrzQf1dQvYyRJR+jf+phjsqwga4+hKouAC5GTbfBjow/coYofi7qD9v IehrjeB5vJNCS7CILEqhMQiqw2yFLg9Slds3XVg=
X-Google-Smtp-Source: AMsMyM7Y22mnYn0+U/hZaIStPwHyZyCtTNaLj4uF/8uaMUEB2o4X8inqvTn6axCBkaJJeaCCEMyDMV79Y0ETyPD2BLc=
X-Received: by 2002:a17:907:a069:b0:78b:c65:e1e7 with SMTP id ia9-20020a170907a06900b0078b0c65e1e7mr4290086ejc.542.1664805779286; Mon, 03 Oct 2022 07:02:59 -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>
In-Reply-To: <CAHej_8mgKjpo6DDbOS9bBdTarThKOa9F55QBtrM6G-oq1YfX+w@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Mon, 03 Oct 2022 10:02:47 -0400
Message-ID: <CAL0qLwYjYY4OvShqACWPz0vdJcAubdU1csFFVSkqzsReZSZxuw@mail.gmail.com>
To: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>
Cc: Douglas Foster <dougfoster.emailstandards@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001830d605ea21cded"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/33dKYeSN-w9r3Yh94jl3G4H3Vts>
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: Mon, 03 Oct 2022 14:03:51 -0000

On Mon, Oct 3, 2022 at 9:03 AM Todd Herr <todd.herr=
40valimail.com@dmarc.ietf.org> wrote:

> On Sun, Oct 2, 2022 at 10:34 PM Douglas Foster <
> dougfoster.emailstandards@gmail.com> wrote:
>
>> I am starting from the viewpoint that (a) reporting is a courtesy
>> provided by the evaluator to the domain owner, and (b) the evaluator will
>> do so in the context of his own interest, which includes filtering messages
>> with maximum possible efficiency.
>>
>
> It is only a courtesy if the evaluator is not interested in promoting more
> widespread adoption of authentication.
>
> For those evaluators who want to maximize adoption of authentication
> (because authenticated identifiers are ones to which reputation can be
> reliably attached and used in handling decisions) it is beneficial to the
> evaluator to provide reports to all who solicit them, so as to ensure that
> the report receivers can address shortcomings in their authentication
> processes.
>
> I believe that the evaluators wanting to promote more widespread adoption
> of authentication far outnumber those who don't.
>

(No hat.)

I think if the consensus concurs with this perspective, then this is
something the document should say explicitly (if it doesn't already).
Specifically, I think the case is being made here that all methods SHOULD
be evaluated, with no short-circuiting, and the results of all of them need
to be included in any report that's generated, so that the report recipient
doesn't get only a partial view of what the world is seeing.

Meanwhile, there's clearly a bar someplace with regard to whether an
operator chooses to generate reports.  I'm sure they all think operators
support the idea of email authentication, but it's not clear whether they
are prepared to make the investment to do so beyond getting the filtering
part of DMARC working.  As Doug put it, it depends on "the context of his
own interest".  I'm not sure this document making a normative assertion
about that part of the question will move the needle at all.

-MSK