Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

Todd Herr <todd.herr@valimail.com> Wed, 28 April 2021 12:34 UTC

Return-Path: <todd.herr@valimail.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 B012D3A28C4 for <dmarc@ietfa.amsl.com>; Wed, 28 Apr 2021 05:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M30hwSym0Jlb for <dmarc@ietfa.amsl.com>; Wed, 28 Apr 2021 05:34:34 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59223A28C0 for <dmarc@ietf.org>; Wed, 28 Apr 2021 05:34:33 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id o1so4882350qta.1 for <dmarc@ietf.org>; Wed, 28 Apr 2021 05:34:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=PO4089PgFjx2YJKO9jqYHfwLldDPzqeaTLjuPnzkhoQ=; b=CL9FJt0xDq39Ib/b1bIYaVWGWzp3bEQCwefg9aD2ttmtmbM9CJpQblvfUKy/xjyFIA 0aTs57dFayeUtmt6t9jXnkXOE99KKmxf7HDHmlvreIha8vpvxieXtqVXZyhvc+i/doL+ tVsEPwU8sgHYgcsHoO0G6NY1PMexqiABxpIxa+BPZbpUYL8PdFVb8pFLNhM9+qd7CZsK C8T+9evP2MNswc8rDgNYAK8OUKLZQcAkCaZ10Okim0x81iYUwQEGpMabSDnSGKHRMWtN W/VUFXuQNWv7yoa+iM84eIgey9FRUun7TkWjlQEli7bi/dDEbbDPVU7DUig9iKPywoc0 L5Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PO4089PgFjx2YJKO9jqYHfwLldDPzqeaTLjuPnzkhoQ=; b=aAtydtHxavjkq7WCiVNrgVzfIpl34ILV0y3TV26ibBmY46jCs7bdKtM5UIv9BBcArK upXzSK7F3guTeapOJOf6unF5RzgTg9+wT/MAztVURAvP+QZR77HG+e7OmkOXavNipP/6 qJYlki7R1xtTQ3Sop2YatF6KW/huD/GtNeZtXfsinK6pyBgrgUjpHhe/rx8EGKUzaaNL 9xuP94zrLZ+Vj4RjJy4VrLRLfDyXonu6fj1/JsUa/OJFSj1k+CV5hBLRHwLbuxgo0usU qU32m1iZ8dShMkdCio396aDnZahvAaK1Y4CHQCHrROj5dqhKl2JOtkzNZJN0vW3c/lXR AFAQ==
X-Gm-Message-State: AOAM530uVEqvBX+Bf3LcWRf+Tanbie6WDS6GGQuMgH1iOJb7IBvho7Y4 L5E1iZ9Sz4XWCE3/N6UPG7/3S6KMBFmJMBUCAeUPhvWeIGUEAQ==
X-Google-Smtp-Source: ABdhPJyetQJwEGQm/bn6U/IiDLS9L3F/D2LkMmtJTI9dAf1ae1Wd+0gI2GlsKvBzKlSv7j5giIEG4XB7AWRhMzPyYAc=
X-Received: by 2002:a05:622a:1353:: with SMTP id w19mr10532950qtk.220.1619613271778; Wed, 28 Apr 2021 05:34:31 -0700 (PDT)
MIME-Version: 1.0
References: <f3d272c6-8adf-0797-cb46-c2166a9e292b@wander.science>
In-Reply-To: <f3d272c6-8adf-0797-cb46-c2166a9e292b@wander.science>
From: Todd Herr <todd.herr@valimail.com>
Date: Wed, 28 Apr 2021 08:34:16 -0400
Message-ID: <CAHej_8kB+B53qFxSAyF9o2mFfC_QXPCobo51cON7ch+UKiKMSw@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd03a505c107993d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/TI_HquaPnbUMK5StQR6Flf9e88s>
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 28 Apr 2021 12:34:39 -0000

Apologies to Matt; I sent this originally only to him when I meant to send
it to the list...

On Wed, Apr 28, 2021 at 4:27 AM Matthäus Wander <mail=
40wander.science@dmarc.ietf.org> wrote:

> Hello everyone,
>
> I'm new to the party. I'd like to bring in some practical experience of
> working with DMARC rua reports.
>
> #23 introduces "receiving_domains" in the report metadata, justified by
> large infrastructures that host a large number of domains (e.g. Google).
>
> I think, this information would be more useful per-record rather than in
> the global metadata. As large infrastructures tend to include many
> different records in the report, the analyst needs a correlation between
> record and recipient domain.
>
> The <identifiers> section has an optional "envelope_to" already:
> >        <!-- The envelope recipient domain. -->
> >        <xs:element name="envelope_to" type="xs:string"
> >                    minOccurs="0"/>
>
> Is there a benefit in the global "receiving_domains" over the per-record
> "envelope_to"?
>
> Most reporters don't include "envelope_to" (e.g. Google). This field
> could be made more prominent in the draft. The main body mentions
> "header_from" only, but neither "envelope_to" nor "envelope_from".
>

There is a hole in my understanding of this topic that I'm hoping someone
can fill here, and that hole is this: I don't understand the value of
reporting out receiving domains.

The reason I don't understand it is because my expectation as a sender
receiving a report about my sending domain would be that my DMARC
validation results from a given receiving infrastructure would generally
not vary across the different receiving domains, regardless of if there was
one domain, ten domains, or ten thousand domains hosted by the reporting
infrastructure. To extend my expectations further, unless I'm dedicating
part of my infrastructure to sending solely to one and only one receiving
site, I would expect my DMARC validation results to generally not vary
across different reporting infrastructures. I'm declaring here that "DMARC
validation results" are separate from "applied receiver handling policy"
because as a sender I can only control the former; "DMARC validation
results" means "whether or not SPF and/or DKIM passed and was aligned and
consequently resulted in a DMARC pass or fail".

If I'm reading draft-ietf-dmarc-aggregate-reporting-02 correctly,
receiving_domains, defined as the "List of domains which received messages
for the domain in this report" I guess it could perhaps help me as a report
consumer in the case where I receive a report from an previously unknown or
unfamiliar to me reporter that hosts many domains, and if that's the use
case, then perhaps the field ought to be amended to "List of the top
$SMALL_NUMBER domains which received messages for the domain in this
report" because as a report consumer I don't need to see 837 domains listed
when realistically one or two will suffice.

What is the value that I'm not seeing in reporting out receiving domains?
-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.herr@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.