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

Douglas Foster <dougfoster.emailstandards@gmail.com> Mon, 03 October 2022 02:34 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 5E337C14F718 for <dmarc@ietfa.amsl.com>; Sun, 2 Oct 2022 19:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_BLOCKED=0.001, 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 o4ulIQzJChQc for <dmarc@ietfa.amsl.com>; Sun, 2 Oct 2022 19:34:30 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 71E1AC14F72D for <dmarc@ietf.org>; Sun, 2 Oct 2022 19:34:30 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id s17so18768ljs.12 for <dmarc@ietf.org>; Sun, 02 Oct 2022 19:34:30 -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=6DKj95Tj4dssB4Bt2ojHnGfceh8B0k31tOF6/uiWbTU=; b=FzhMNW/tNhKsybKDh/6B/ECqyouTTrNfqeRBBB2QJwT0WzogqY4dnm2Y4777yl43DH OthB1sLLtSc/ov62ajre9/HspHYdeswWLZkNSFvwBR6Li6dcgKBYA6Gr+NviffXsVbgi U+oesaFdda9Xz107EwqpmBkB/vvrZoh6rwqJsBZdLsAPh7SK/tWWsQcC/ykTwcbHneCw 4KGxIuJ7fDjrxbrGWrLaq6/hP6VTVD7tfjtBzrbw7khGPmGo00pv6iHylu/vKVTeldFo IqHg1a+u2k8rIivzqf/Z4P8v8MmQOCgR8kqufnV+rxNHdkVX1n0CMwD7hs7HxQg47Zko z58A==
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=6DKj95Tj4dssB4Bt2ojHnGfceh8B0k31tOF6/uiWbTU=; b=EmSCM6ZWbf/Q7b6RFqdvSjbUVAQcnUJDlO6rzWu8HOJKsNPaglinNk9TrBDyj3nVBc TjS0uN/G5i5DhK8XuYL0/aOSQFlPUZpjxwz0QB71j1eXThwQl3oKskTpJ39iA6spewzI cij/AQwycLl95ggMYE3dquO6AiSFGiSTZ8KroiXJvoSEz2xvjVNbULd6e4bsryEMFdMo MK95x02f6nxi/zmw7Z6vDOYNmWE+21eSnWulFEtngo1NcV6dY8WGhU6+8HVAiLO/wAmx vkVbBis8/6aTPcVfRB6VZ+mhFQRJeOhFU4X0VXj5x2fVEIPleNLlGZvW3sjtYo1rx58K nx9Q==
X-Gm-Message-State: ACrzQf2k10IFrsyyH2btNA92ywYTLJpZKW5x30OKRsKchvY0EYbA8SGv j6HxewywrMdAtVk4QFIV9uXot0QdX2KftCN7UyqkYAJE
X-Google-Smtp-Source: AMsMyM7vBVPG7npYLzJpxe12fmS3iP70tDhlCj5IxfyJNLCTKWEJwy8KnB8nivGTH5/FquNHWDTmBaAfX+Lr76wNzHw=
X-Received: by 2002:a05:651c:1508:b0:26c:622e:abe1 with SMTP id e8-20020a05651c150800b0026c622eabe1mr5698088ljf.228.1664764467524; Sun, 02 Oct 2022 19:34:27 -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>
In-Reply-To: <CAJ4XoYen6n06L1UBqzu9nr2jCC7v_-GOAdJXMzCks6d-AaKqUA@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Sun, 02 Oct 2022 22:34:15 -0400
Message-ID: <CAH48ZfzVt=+yoj280VxL_SV+YM4C7eqMWhL=41YpVybaPmLcLg@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b8b6c005ea182e64"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/jZdF_fJMZPDbRw52N_qE1yTDh2M>
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 02:34:34 -0000

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.

This WG can certainly impose a requirement that an evaluator MUST evaluate
all available identifiers, up to the specified limit of 100, to be
compliant.   Evaluators that are not willing to be compliant MUST not send
aggregate reports.   We do not have that language yet.

Doug


On Sun, Oct 2, 2022 at 5:00 PM Dotzero <dotzero@gmail.com> wrote:

>
>
> On Sun, Oct 2, 2022 at 2:01 PM Douglas Foster <
> dougfoster.emailstandards@gmail.com> wrote:
>
>> In many cases, an evaluator can determine a DMARC PASS result
>> without evaluating every available identifier.
>>
>>    - If a message has SPF PASS with acceptable alignment, the evaluator
>>    has no need to evaluate any DKIM signatures to know that the message
>>    produces DMARC PASS.
>>    - Some identifiers are easily excluded by simple inspection:   A "
>>    sendgrid.net" identifier cannot authenticate "example.com"
>>
>> When the evaluator has an identifier which is known but not evaluated, he
>> does not have a way to document this outcome in the aggregate reports.   To
>> fix this hole, we should add an authentication result of "not evaluated"
>>
>> Doug Foster
>>
>
> It is absolutely a wrong thing to suggest not evaluating DKIM if there is
> an SPF pass. One of the purposes of aggregated reporting is to help sending
> domains to understand the what is breaking in their mail streams. SPF
> PASS/DKIM PASS is totally different than SPF PASS/DKIM FAIL. The overhead
> cost to perform the DKIM check is relatively low. Why wouldn't you do this.
>
> Do you believe that preventing a sender from getting this additional piece
> of information is a good thing?
>
> Michael Hammer
>
>
>