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

[Brandon Long <[e-mail]>]

On Wed, Dec 9, 2020 at 3:48 PM Jesse Thompson <jesse.thompson=
[e-mail]> 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.

Brandon