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

Todd Herr <> Thu, 29 April 2021 12:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49DFD3A3D63 for <>; Thu, 29 Apr 2021 05:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, 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 dWK9K919TkzG for <>; Thu, 29 Apr 2021 05:44:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C7333A3D65 for <>; Thu, 29 Apr 2021 05:44:23 -0700 (PDT)
Received: by with SMTP id d19so31225485qkk.12 for <>; Thu, 29 Apr 2021 05:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=c2w3Uf9ZIHkMz7KKaOmiGMJyvAuAaybxqVItZYoGsbw=; b=b1Wn5Wu+AamPf9ptno8YG2aJFH7hD7hd9flZUcy88vy4wnP5yv/NtsCzWeZfS4OH0h iXKWxN9hujDsbqw2XAw9jlmyWzEREQswMKTP8pHsQpixC6NqciAYeGmJa/OQXUGsfiW2 n+L96V5a/ERaHhlASOXanI4hkx/eBsQWIo0nzD+7s7wzhzADrpD4+A0QbH9JZQwnrR73 wiTrntdSSE0uwPXS+NtLmxD1FoEWh9DGTqObWlpEBDz0p4hsqYN0PpvV2pu10wn8KZ75 udwzA5baY+uJBAo+4vS/7JcxIw9eCVcuDl7bS2c64YDP9KHAPmHOyZBChrnAzuePusw+ yuew==
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=c2w3Uf9ZIHkMz7KKaOmiGMJyvAuAaybxqVItZYoGsbw=; b=lfQklBeVtBJTf27UgwsoT5E3an5TKmPJPRr/9JgrL3k5ww18m6vOZidwlPDVY79r/f TdJf9FbkgATGzYzlAquSF+bfwcYyH1RtrMOxivrps+gBNgeA0C9QR83GxD3uoNG3X4Up m3Ul+otRRk6AncnrzMoE0DRsdqFnyTDWMpj5rnw3Rogf4IWqvKK+usw6fokCQqizsYA8 BbzCWhV+J/w4oe/9kPyLPMmNoTBF66SlNnJOL1gRNoiFRYaeFFj7nzYciOjt1Jt3cPpl rm22XGENNsW0Ayzpa/DEbsml3aoAJarwbRx+Lj2aP70Ym90Zjg1Sh3sfWc4wNSP6PhVC 0UFQ==
X-Gm-Message-State: AOAM531FEvuIzSga5ou2g/oq/ZPji3x3ZE/rM1INDSuBRmCtX8xqng/n HKWRz+lT14or+cIz0HnMBsPtyrb+b9tRPhU62s3scoKf95Q=
X-Google-Smtp-Source: ABdhPJz2/TcvwNgLFyzAnjSLESJeEUZEFcjPR55EVDK73PZz9NkQ9PQY8TOpv6GpkQ5Xv39LPHV/iXwb3YlH/ePH8tY=
X-Received: by 2002:a05:620a:204b:: with SMTP id d11mr33547615qka.456.1619700261104; Thu, 29 Apr 2021 05:44:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Todd Herr <>
Date: Thu, 29 Apr 2021 08:44:05 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000b4c14b05c11bdac9"
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 12:44:28 -0000

On Wed, Apr 28, 2021 at 9:22 PM Douglas Foster <> wrote:

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

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

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.

> In short, what are the expected uses of the RUA reports?   Are there any
> 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.


*Todd Herr* | Sr. Technical Program Manager
*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.