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

Douglas Foster <> Thu, 29 April 2021 01:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D34A53A285E for <>; Wed, 28 Apr 2021 18:22:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LZOQl7aTczo7 for <>; Wed, 28 Apr 2021 18:21:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31B063A285C for <>; Wed, 28 Apr 2021 18:21:57 -0700 (PDT)
Received: by with SMTP id e25so34992326oii.2 for <>; Wed, 28 Apr 2021 18:21:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=tgcau1h4F6cd/V1KzNKqvvbO+5Q+hRnYWLopqM++JGM=; b=fLFC4i7Ab4rwg9ldiM+Ou+Tz6aT4z9PK39hZaoEqKgG8U7C8QMsd9n08b3PqumdjfZ 7dXrrW4JeZIYBpaoqI/cvCLI9tCMVjud/lfahSPYDAtsbZQWrUSrE/qMVUf6gUgLGVLb 744bcQEG2MC9L2ErNSvU52HUyExE7ab+FTxfc7eesB9ocHA3TU7C1NvQ+GG+Z7GcqReB zFIGC3Ws9V1QI1vFruq8zwxftJ9p7flzpnOKlkWKlNOaW+czXMqeCj3L2LjEYi7AhcIi aOpfARGL/aV76iViMlR0DGKUB+2dl9755OICclm/u7/PtUOkx5WyJF8DAj7F4NLHT6mA v0mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=tgcau1h4F6cd/V1KzNKqvvbO+5Q+hRnYWLopqM++JGM=; b=T7gKefRuVq+6+nWcmI1G5zdXxN2+0FaLSn0IcItqk3mGwMR7N0f1uSvYahpUkxYLUe BqdPW3Xkux5DJctquT1nfCNtdXCx+EcsxBgt3MJlFhpWOsqTJoTPbCgRmoHgI7upV0jO Y+OnnuwMPHUAkIRH5FMJq3D4FrMFg+p2E1XT7LFJnAr0MUmszm1ZMr2a+jLNdCI5tkj7 cp4inLdIWzhMxqHmySFcsYa0eFZ7cs1O6tx3AwBTejkFGR5O0ooBiiLQrRfETwEdtPd+ g3XJ+j8QM+WCrnc0Hl0eAuqwioReAH542dimvVmG+oeB6TwAa7T0hborpP200boXyOZ/ 09dA==
X-Gm-Message-State: AOAM532235/udmdd+2WT/aamJS8DfkGXo1PImJKU49pEUoBYQxhAx81d NWwJcxRFNWL+BqBTrNea1ml3povQ51Ndj40wfNn6aVrF
X-Google-Smtp-Source: ABdhPJwebgSh9opIGikS4+0maDowQ1jPvfU9HhYc0hQbMdjNyZDrxhJHlw6IvN2D+7HWuGe3oEfXwkD3+qyutXMl7tw=
X-Received: by 2002:aca:bb0b:: with SMTP id l11mr5009851oif.146.1619659315597; Wed, 28 Apr 2021 18:21:55 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Wed, 28 Apr 2021 21:21:45 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000029d60105c1125292"
Archived-At: <>
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Apr 2021 01:22:02 -0000

I understand that additional detail might make the reporting effort
unacceptable to the big organizations that are creating them, and this
reason alone may prevent alternatives.

It seems that the potential uses for reports are:
- Identifying and fixing my own infrastructure problems
- Celebrating when the reports show that I have no new infrastructure
- Celebrating when malicious impersonators are blocked.
- Learning about non-malicious impersonators that must be tolerated.
- Identifying delivery problems that warrant a conversation with the
recipient organization.

I cannot successfully call a recipient help desk and ask them why they are
blocking my messages.   Instead, I need a message recipient to call his
help desk and ask why he is not getting my messages, and that subscriber
might be happy to be asked for assistance    Navigating from a server IP
address to a known subscriber might be no easy feat, while navigating from
a server IP and target domain to that subscriber would be easier.

In short, what are the expected uses of the RUA reports?   Are there any
intended purposes other than fixing my own infrastructure configuration?

On Wed, Apr 28, 2021 at 8:34 AM Todd Herr <todd.herr=> wrote:

> 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=
>> 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:*
> *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.
> _______________________________________________
> dmarc mailing list