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

Neil Anuskiewicz <neil@marmot-tech.com> Thu, 20 October 2022 00:42 UTC

Return-Path: <neil@marmot-tech.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 2BB70C15257D for <dmarc@ietfa.amsl.com>; Wed, 19 Oct 2022 17:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, 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_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=marmot-tech.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 nKEvJEI8yb8y for <dmarc@ietfa.amsl.com>; Wed, 19 Oct 2022 17:42:46 -0700 (PDT)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 E24EDC1526F5 for <dmarc@ietf.org>; Wed, 19 Oct 2022 17:42:09 -0700 (PDT)
Received: by mail-pl1-x629.google.com with SMTP id k9so18385694pll.11 for <dmarc@ietf.org>; Wed, 19 Oct 2022 17:42:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marmot-tech.com; s=google1; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=NV3hvPRrz78q3EB1FEamraReIFRHmahFckAw0yuaXU4=; b=V57a7jgNFFkEqEtB+C9Q9MkgoblWcWwWR6KLPkIq79hYbIwyTUYqSw8nQu6CScBXyG rOkFHw4GL+wlaYbWISgLm3AmcZyfg+HeNjedJfkptloZ+fh/cd/vNIwDrIotNRbaRarO aFvT/DU4f2atFYvdRt85qnyoEdL5lnUZEf0shuBGPtNNk0pp0o7Y/7S2gBhT/gQNA1xr S+fRTQFr3wdebGo0UCbk+aVxQQsZjL0MFRNnLUktPhPRn09wXErzbiQgJmLumJG9PU8R WOkNYQehqNdHlUDVb1MhyClpt+5IeEuUfjfGE5Z42DwGlAZ4NX1ZMPi+tC2nHWStjwJU aXKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NV3hvPRrz78q3EB1FEamraReIFRHmahFckAw0yuaXU4=; b=cBxS/OE+dofp+KynZZHEjqcIjW53upOAUB8UkV/SXbiXmDETi6fk4FJkCMkyzi4rlo P2wkGXGE/QTF8vbZUlQKOeTzvCKyvNzz3FZGZrvY5pZLmicqTdjQabhBpmI0673s8co9 6dO3PAiW2OINFmRRWS89C0MpTdQ5VSuxtAKA8lTJ/b9HPSTOEh4wTZVV6HbybedkC08s 1lcggB3nk+bkYpKtSBS6VySSmZ0g4CDRj7jJ0Fm3MoT2VSfUo5zJCnY9HTvW1AgRT1XD qOXkX6MAs8whsv1V1SQ/Lw5aD2287El7oqQDTSdmyMHbjFHuSzgIKZSc0aj/e4DZNXkm 8ehQ==
X-Gm-Message-State: ACrzQf01f4hsHT0d3iUCRBSa2DyzQZM49dra5KuDwYhq+TtJyzbyQ+S5 9TtRXp4yqvolfLatVGfDJBRo/Z7fYtHjwjXY
X-Google-Smtp-Source: AMsMyM5EtaWoGPBeR6LSuAM7uIp9HkXdLpS0uNXFyibvkMxfJBENlORbIR12B6vIuZavkHndKdmPew==
X-Received: by 2002:a17:903:41c4:b0:186:6019:d489 with SMTP id u4-20020a17090341c400b001866019d489mr1715036ple.127.1666226529023; Wed, 19 Oct 2022 17:42:09 -0700 (PDT)
Received: from smtpclient.apple ([2601:1c0:cb02:fad0:212b:7b82:8a34:500e]) by smtp.gmail.com with ESMTPSA id b14-20020a170902650e00b00174fa8cbf31sm11220616plk.303.2022.10.19.17.42.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Oct 2022 17:42:08 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Neil Anuskiewicz <neil@marmot-tech.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 19 Oct 2022 17:42:07 -0700
Message-Id: <9D6D6E80-B0B0-4CAD-B301-B0A17F9C6663@marmot-tech.com>
References: <FCE0708E-CE6A-4E0A-B5D0-F735779FFAFC@kitterman.com>
Cc: dmarc@ietf.org
In-Reply-To: <FCE0708E-CE6A-4E0A-B5D0-F735779FFAFC@kitterman.com>
To: Scott Kitterman <sklist@kitterman.com>
X-Mailer: iPad Mail (19G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/MUcYthhNmyTdy5fiiA0cx2tox-A>
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, 20 Oct 2022 00:42:51 -0000


> On Oct 19, 2022, at 6:59 AM, Scott Kitterman <sklist@kitterman.com> wrote:
> 
> 
> 
>> On October 19, 2022 12:44:16 PM UTC, Dotzero <dotzero@gmail.com> wrote:
>> On Tue, Oct 18, 2022 at 11:18 PM Scott Kitterman <sklist@kitterman.com>
>> wrote:
>> 
>>> 
>>> 
>>> On October 18, 2022 10:16:44 PM UTC, Neil Anuskiewicz <
>>> neil@marmot-tech.com> wrote:
>>>> 
>>>> 
>>>>> On Oct 2, 2022, at 11:01 AM, 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.
>>>> I think it’s critical to DMARC that receivers do things like evaluate and
>>> report on DKIM whether or not SPF passes and is alignment. Without this, it
>>> would make it harder for senders to notice and remediate gaps in their
>>> authentication. Since there’s not a downside (that I know of), I’d say this
>>> should be a MUST if at all possible.
>>> 
>>> 
>>> What is the interoperability problem that happens if evaluators don't do
>>> that?
>>> 
>>> Scott K
>>> 
>> 
>> Scott, What is the interoperability problem is evaluators didn't provide
>> reports at all? Reporting isn't a "must" for interoperability but it
>> certainly helps improve outcomes instead of senders flying blind.
> 
> I read the email as suggesting a MUST for reporting both SPF and DKIM results if you report results at all, which would, I think lead to exactly the situation you're concerned about.  I'm skeptical of any kind of MUST around reporting since that's generally reserved for things that impact interoperability.  I do agree it should be encouraged.
> 
> Mostly, at the moment, I'm trying to understand the proposed change and the rationale.

I think the reactions were to the tone that that seemed to suggest that the importance of reporting was being downplayed. MUST is too strong and strongly encouraged is sufficient. The standards system relies on people making a good faith effort. To me, Doug’s comments came off as wanting to weaken the language which concerned me. 

Reporting is key for DMARC to work as a system so any hint of weakening that language or even could be interpreted as such caught my attention. I think Doug clarified his position as addressing specific cases not a weakening of the reporting language.

DMARC is about the interests of the system but following the standard strengthens the system within which the sender or receiver operates. Even if one wasn’t interested in the health of system in and of itself, reporting benefits the admin as it increases security and reduces broken authentication. A *LOT* of Senders use reporting data as part of the process of fixing their own and third party senders they wish to allow or spoof, discovering errant shadow IT, etc.

Reporting is or core importance for everyone if for no other reason than to avoid headaches. Thanks.

Neil