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

[Jesse Thompson <[e-mail]>]

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.

Alternatives:

- Assuming that all ESPs were cooperative to inquiries from domain owners, and there was a consistently-used internal identifier that could be referenced that doesn't directly disclose publicly identifiable information about the customer, then that might be all of the forensic information that I would need.  But fall back to From/Subject, otherwise.  

- SPF macros can be constructed such that the envelope information is sent back to the domain owner via DNS queries.  This tactic is handy only if there is something identifiable in the local part of the return path.  The downside to this tactic is that you're spraying unencrypted identifiable information across the internet.

I guess that I'm leaning towards encouraging redacted reports with some minimally identifiable information.  The reporters still have the option to not send reports (or redact however they see fit), and domain owners have the option to not request reports if they are concerned about privacy.  

The potential downside to not having failure reports at all is that potentially less secure/private mechanisms may be adopted due to demand (such as SPF macros, sketchy data warehousers, etc). 

I did purposefully ignore the use case for using DMARC failure reports to track direct domain abuse, which I assume is a valid use case and should be considered in more depth.  I just don't have a direct experience using that data in any meaningful way.  Perhaps it could be used in a way that articulates the *actual* amount of direct domain spoofing being used by malicious actors, as opposed to aggregate reports which only gives you IP addresses (which may be enough if cross referenced with reputation lists).  Obviously, if you rely on the full details of the failure report to build anti-spam heuristics, then you wouldn't want the reports redacted.  But if you are in that business, I assume that spam traps work better anyway.

>From the original ticket, I am failing to completely understand why "aid identification of the email's destination" is more useful than identifying the [true] origin.  I suppose it could be useful for organizations who want to validate the use case (make sure they aren't sending unsolicited messages, etc) before adding another server to SPF (without talking to them?).  That's just not something we do, since we have a Holy Roman Empire and let people do whatever they want with their own subdomains.

Jesse