Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report

Brandon Long <> Thu, 10 December 2020 00:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B39F3A0888 for <>; Wed, 9 Dec 2020 16:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 kwgN3Emkk1op for <>; Wed, 9 Dec 2020 16:12:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D520A3A09CC for <>; Wed, 9 Dec 2020 16:12:30 -0800 (PST)
Received: by with SMTP id r24so1919785vsg.10 for <>; Wed, 09 Dec 2020 16:12:30 -0800 (PST)
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 :cc; bh=YzowFg+2X8k54S1OMcmV742PCltHLZp4UHI5bJP9kD4=; b=o7J3F5OBA7g8XphgT+z+Mzl3xBxb884H7XL94hqjRazk4S21gbAJmydKqIkftBGboW gKTXOQz/o/KiCP1aeqeoGYCSwoIvJ68xPn+9v6hF/YyyJeQyt4ALFQ1QRg7WsWYrOJQe eJDdilsHHUbJl7S1gh349/NNuBlc+ULZJfsXXnIILvjAs6cY0T3St0OHyhwv5TcDT0ya cG6x4Roab6thjOkfsOjlQGSNAp9KdklISVy48afFUPT67aO0gFF7J5htrP6n2nm9AxY0 eD7sW/r7X4rWu0Z88nsUhpTm3ahWmBTMLqq8qF9SEQ94p2wlQZvZwN4WcvDEEN04T1um /yYQ==
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:cc; bh=YzowFg+2X8k54S1OMcmV742PCltHLZp4UHI5bJP9kD4=; b=FlLw3GTeikGAlV/fHgALu+YPP1dpFW7cz2TlWs/taK3xUF2csT8WRxszhQAhJ17ig8 AuhHwa3k4tNTRH6vsg/EqUWU3pc/xE1R7vuSR/3EhKgeCCANBhRmPmE21pY7oox9s5Ho ZRf6dqV4YZxRMr9r8uTp6xVtiCBzijemhFLxyKduWihOUW22nLrvQXiUYhl+oycmPZdn oCSUwxNCNLwk4d/djcO8PhgjJIY7PlAR/m2e0gmaceJ/hCGIcoGKNuHJOZa4WKFGu+92 bHF97aXRphc0fY6gkP5fpuliLRUAovJe08t4eeBaFW+DSQW9KPBG71irfLKOQorWSmk1 ZVbQ==
X-Gm-Message-State: AOAM530s11pobko7WwptKZhjhE7MZCUA52RMA+oAz8WDwCzkoMIpDPhU xx6hTRLNMWHh8aYvh0qPPFUbaQaySKS4izYfNzRyiGqkiA==
X-Google-Smtp-Source: ABdhPJwEei8ej3XxzPDuvEy+XEFMcQQ8FxAfywRQZ4/dAEEXh8uNjt99RUVaE+4PIozSDds8OIxXJGKfeFAY/rpvx24=
X-Received: by 2002:a67:df8b:: with SMTP id x11mr4914065vsk.37.1607559149635; Wed, 09 Dec 2020 16:12:29 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brandon Long <>
Date: Wed, 9 Dec 2020 16:12:16 -0800
Message-ID: <>
To: Jesse Thompson <>
Content-Type: multipart/alternative; boundary="00000000000012424a05b611080f"
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #61 - Define and add a simplified (redacted) failure report
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, 10 Dec 2020 00:12:34 -0000

On Wed, Dec 9, 2020 at 3:48 PM Jesse Thompson <jesse.thompson=> wrote:

> On 12/9/20 11:07 AM, Alessandro Vesely wrote:
> > We would like to close this ticket by Dec 23, two weeks from now, so
> please get on it.
> >
> > The ticket text is:
> >
> >     It has been asked for a new report type (perhaps a subset of failure
> >     reports) that provides minimal data from the email (specifically, the
> >     initial ask is for the to: and from: email addresses only) in order
> to aid
> >     identification of the email's destination (and hence, the owner who
> can
> >     help with getting it authenticated) without providing other PII.
> >
> >     This is a significant use case for large organizations, where the
> >     departments or other sub-organizations run their own emailing
> >     infrastructure. This has been specifically requested by multiple
> >     universities.
> >
> >
> > DMARC failure reporting is based on Authentication Failure Reporting
> Using the Abuse Reporting Format (RFC 6591), which in turn is based on An
> Extensible Format for Email Feedback Reports (RFC 5965).  DMARC adds five
> fields for the second MIME part of the report.  The third part can be
> either the full message of just the rfc822-headers.  The latter is defined
> in The Multipart/Report Media Type for the Reporting of Mail System
> Administrative Messages (RFC 6522), which mentions that Received: fields
> can also be useful for diagnosing failures.  In any case, private data such
> as the local part of email addresses can be redacted according to Redaction
> of Potentially Sensitive Data from Mail Abuse Reports (RFC 6590).
> >
> > In order to be useful, reports should contain enough data to discern
> whether the failed message was abusive, and what stream does it belong to
> if it wasn't.  Should DMARC Failure Reporting (our document) include some
> guidance about what parts of the failed message to include and which ones
> to redact?
> During our DMARC deployment (and even today) I was frustrated that I could
> see from aggregate reports that an ESP (or some other type of hosting
> provider whereby the IP address alone wasn't identifiable enough) was using
> our domain, but I didn't know who within our organization was a customer of
> the ESP.  Ultimately, I wanted to reach out to the customer and set them up
> with a subdomain to use with the ESP so they could send branded and DMARC
> SPF&DKIM-aligned email.  Asking the ESP who they're allowing to use our
> domain was a dead-end because they considered that private customer
> information (irony!) and they're naturally inclined to make their customers
> happy by tolerating the use of the domain without complicating matters that
> may result in possibly losing the customer.
> Forensic reports are a useful mechanism to find examples of these messages
> and subsequently track down the customer on our end.  Usually, seeing the
> local part of the address used in the From header (maybe coupled with the
> Subject) was enough information.  I did struggle with the needle-haystack
> problem with these reports.  It was challenging to find what I was looking
> for, and it was challenging to create a process for going through all of
> the reports in any meaningful way.  Perhaps I didn't really find the right
> tool for the job, or perhaps the problem wasn't large enough for me to
> justify finding/developing the right tool.

Of course they are useful.  There are a lot of potentially privacy invasive
things that are useful.

At best, we considered allowing RUF reports for cases where the dmarc
domain was the receiver, ie if someone had a message that failed dmarc
while sending to the same domain, then presumably the domain admin already
has the power to view the message.

But, if you limit it to that level, then the domain admin could already
theoretically do this themselves by having those messages delivered to some
destination to look at them, or setting
up their own forwarding rule to their dmarc analysts.