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

From: Matthäus Wander <[email-masked]>
Date: Wed, 28 Apr 2021 10:27:21 +0200

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".

Regards,
Matt

---

From: Todd Herr <[email-masked]>
Date: Wed, 28 Apr 2021 08:34:16 -0400

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

> "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:* [email-masked]
*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.

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 28 Apr 2021 12:56:52 +0000

Matt,

While, yes, there is the existing envelope_to, there was a request to add this to the report format (which I believe I did as the submitter desired).  I would assume we’d hash it out on the list and remove one of them.

However, from an operator side of things, I tend to align with Todd on this.  Could someone provide a real-world example of where reporting the destination domain assisted them in resolving an issue?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc <[email-masked]> On Behalf Of Todd Herr
Sent: Wednesday, April 28, 2021 8:34 AM
To: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

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=[email-masked]<mailto:[email-masked]>> wrote:
Hello everyone,

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: [email-masked]<mailto:[email-masked]>
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.

---

From: Douglas Foster <[email-masked]>
Date: Wed, 28 Apr 2021 21:21:45 -0400

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
problems.
- 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=
[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Todd Herr <[email-masked]>
Date: Thu, 29 Apr 2021 08:44:05 -0400

> - Identifying delivery problems that warrant a conversation with the

I believe all of those things are already possible with the aggregate
report as it is now, with no need to list the recipient domains. For any
set of X domains hosted at provider Y, I would expect DMARC validation
results (i.e., pass or fail) to be consistent across all X domains at that
provider.

> a server IP and target domain to that subscriber would be easier.

I read this and I perceive that you are assuming that DMARC failures will
be the only reason for mail to be rejected, and that all mail that passes
DMARC checks will be accepted. Neither of those assumptions are necessarily
true, and many if not most delivery problems will be independent of DMARC.
DMARC allows for reliable association of an identity and its accumulated
reputation with a mail message, and it's that accumulated reputation that
will drive whether or not the message is delivered.

> intended purposes other than fixing my own infrastructure configuration?

Regardless of what the original intent of the aggregate reports might've
been, for all practical purposes they're only valuable for auditing one's
own authentication practices and configuration, in my opinion. It's
actually a perhaps underappreciated feature of DMARC, in that one can use
DMARC at p=none to conduct a full and complete audit simply by consuming
aggregate reports over time and addressing problems with one's own mail
streams that the reports might show. Once enough time has passed and the
report consumer is sure that all of its mail streams have been reported
upon and are properly authenticating, the domain owner can publish a more
strict policy (p=quarantine or p=reject) if it so chooses. For
authentication failures shown in the reports that are the result of mail
the domain owner did not send, I haven't yet met an abuse desk that will
act on anything other than headers (assuming that they'll act at all), so
it's not actionable data. The value in this subset of the data really lies
in seeing that such mail ends up failing to reach its destination once the
domain owner changes its policy to something stronger than p=none and
report generators start to honor that policy.

--