On Thu 10/Dec/2020 00:48:12 +0100 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.
[...snipped Alternatives:...]
I'm a bit lost about where we are at this point.
The possibility to redact parts of the report is already mentioned in the draft.
We could add the generic possibility to select which header fields to include
in the report. For example, the draft might suggest to only include known
header fields. That way one could drop all X-* fields with unknown binary
content and any other scaring stuff. If one wants to only leave From: and To:,
so be it. Their reports, their choice.
Otherwise we can just close this ticket with WONTFIX.
Opinions? Other ideas?
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
