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

Douglas Foster <dougfoster.emailstandards@gmail.com> Mon, 03 October 2022 16:38 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 4AA2AC14F73D for <dmarc@ietfa.amsl.com>; Mon, 3 Oct 2022 09:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=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 iTGY2q1lpHFX for <dmarc@ietfa.amsl.com>; Mon, 3 Oct 2022 09:38:15 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 7BCC4C14F75F for <dmarc@ietf.org>; Mon, 3 Oct 2022 09:38:15 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id j16so17421869lfg.1 for <dmarc@ietf.org>; Mon, 03 Oct 2022 09:38:15 -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; bh=QeEr8t/OXF4PAByHxe40cfXywNbpY1lscL3ewYXf9ZQ=; b=BKNbsgp9GnvKswXItdVnRrwYOa2aEwb074482RYtxBVM0DyGDrl9Bydvmiqca7AkRd BdIUdmh3WGZGManVFze1zKLk8mLMn1a+S+k1N4z5b6dAaEBU1h7ZMLJH+Lx+KfTIq/pg XsvXyuHSUzTDw4zIG4N7Jlpj2bRP7llI2hJZWfCb10L7veDYy4q6iCm9wdspwTW2G18G nlj4My2uti0V49OxKj4l0rj3y0ZqB8XIxF2SEYcylr75z8sNjn4F8cbPn3ZX24v+w5uR W/7XcjfSfb1RXl8SS4DjH/spao7bGD89QdGGAusOE+ciG9l/RsbIgUa85CpsaBj5G4S+ +JGQ==
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; bh=QeEr8t/OXF4PAByHxe40cfXywNbpY1lscL3ewYXf9ZQ=; b=DtvF9Ed4Adu65eb4lfYlUx+1mr50fv9RgX8jTR8ivdVIyFGuF7kusEOSw6cJrz1zcp 5TuVoqvGliiWq9jvr6a854i1YCZc/gL/hMO8sSJ4J3g3bbykJ6V+ISpl/yObuUDHYlx3 KXuY1gOR6KJD65iiXm5VWI1ain8Jp/9WDB4ed/es5FiB0EZH3q45GZaMjfOjC2MWwKm2 vu9TlGJV63tGAL1VhQP7w3joygNo1LcmMFFY9Et/T3xhhsqjXyizbteYpf/WO9XFhwlH 3dp1Jwfo5mNRzKmT3Z9oy1pei/OY2eofg2nb65RIDDhzzaMb+6ZWwJezuPhQzQmfLU7b pPpA==
X-Gm-Message-State: ACrzQf2HJUy5SJYNRv6o0ugBgcWv8Dww3pH6COSi4vFH3t9kAKU7rLnm cdwgOMrJtzuwFkYEfYs5Pn1EsctEYjuGHABQgnE3Lkoi
X-Google-Smtp-Source: AMsMyM6UV62hm5Zd+cVQt5V9RqjrHrfMKwmAtq+zCoOvGDmQuMQno2IxaG3NeEnwR3NzTQJIiOdEwJgMPpJyZaDeAv0=
X-Received: by 2002:a05:6512:149:b0:4a2:2e09:6681 with SMTP id m9-20020a056512014900b004a22e096681mr3197375lfo.36.1664815092530; Mon, 03 Oct 2022 09:38:12 -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> <CALaySJJ2za=j0-syG_HFAtvPQjAvLuXi_7s21cteDfnGM8anCA@mail.gmail.com>
In-Reply-To: <CALaySJJ2za=j0-syG_HFAtvPQjAvLuXi_7s21cteDfnGM8anCA@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Mon, 03 Oct 2022 12:37:59 -0400
Message-ID: <CAH48ZfzTM95hA9VoEWkWjhvDZ+HvzMA15K27F2=9Tiu3ABJ3Bw@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000035028505ea23f880"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/7k4UgcQ9CILO8yKU4R-i3_rBmKA>
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 16:38:19 -0000

If the evaluator takes shortcuts, our options are
- please don't report at all
- please report only evaluated identifiers
-  please include identified but unevaluated identifiers using a
not-evaluated status
- please include evaluated identifiers and a Flag event to tell the domain
owner that results are incomplete

I have no strong preference as long as the possibility is addressed.

The not-evaluated status provides the most information.

The incomplete flag handles all possible causes, including an evaluator who
exits the process without parsing the entire header set.  (Hopefully the
least likely event.)

These two options inform the domain owner that data is missing, which seems
important.

Doug

On Mon, Oct 3, 2022, 12:10 PM Barry Leiba <barryleiba@computer.org> wrote:

> Personally, I think the right approach to this is a section about the
> importance of reporting to keep domain owners informed and aware and
> to promote wider adoption of authentication and policy protocols.
> That section would say that reporting SHOULD be done for those reasons
> and would explain the benefits.  That would make it clear that the
> SHOULD is not for interoperability, but for the reasons laid out in
> that section.  And then we use no further BCP 14 key words about
> reporting, allowing that section to carry the message.
>
> Barry
>
> On Mon, Oct 3, 2022 at 12:01 PM Murray S. Kucherawy <superuser@gmail.com>
> wrote:
> >
> > On Mon, Oct 3, 2022 at 10:26 AM Brotman, Alex <Alex_Brotman@comcast.com>
> wrote:
> >>
> >> So we would likely need a section in the core document with a SHOULD
> for evaluation (if it’s not already there), and then a section in the
> aggregate reporting for a MUST for reporting on evaluated information (if
> they choose to send reports at all), correct?
> >
> >
> > I'm having a hard time coming up with a crisp answer to this.
> >
> > From a security perspective, failing to do either of these doesn't
> create any sort of security exposure, so neither is justified.
> >
> > From an operations perspective, you could argue that doing both is
> necessary for robustness and operator sanity (i.e., the complete picture is
> recorded which enables debugging), so both are justified.
> >
> > From the actual protocol standpoint, the filtering part of DMARC
> operates just fine if you make the shortcut Doug is proposing, so the first
> SHOULD is probably apt but the MUST is moot because it doesn't change
> interoperability.
> >
> > I guess it depends on what we think the priority is.
> >
> > -MSK
> >
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
>