Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

[[e-mail]]

> On Mon 28/Dec/2020 15:54:24 +0100 ned+dmarc wrote:
> >
> >> I still think it'd be a good idea to mention RFC 6590...
> >
> > Why? RFC 6590 documents a generic approach to partial information hiding. It
> > does not specify how to apply this technique to DMARC failure reports, and
> > doing so effectively requires a careful assessment of what needs to be hidden
> > and what does not, and that in turn drags in all of the specifics we need to
> > avoid in a base document of this sort.


> The failure-reporting draft references RFC6591.  The only appearance of the
> term "redaction" occurs in the 2nd paragraph of Section 4.1:

Referencing an approved standards document on failure reporting formats is
perfectly reasonable and even necessary.

>     These reports may expose sender and recipient identifiers (e.g.,
>     RFC5322.From addresses), and although the [RFC6591] format used for
>     failed-message reporting supports redaction, failed-message reporting
>     is capable of exposing the entire message to the report recipient.

> RFC6591 doesn't go into a very detailed description.  It references RFC6590:

>     For privacy reasons, report generators might need to redact portions
>     of a reported message, such as an identifier or address associated
>     with the end user whose complaint action resulted in the report.  A
>     discussion of relevant issues and a suggested method for doing so can
>     be found in [RFC6590].

> RFC6590, in turn, avoids the specifics of what exactly needs to be redacted.
> However, it mentions the local parts of email addresses.

If anything this is an even stronger case for not referencing RFC 6590 here -
it's unnnecessary because the reference is already in the failure reporting
format specification.

I also note that RFC 6591 was published in 2012, long before PII became such a
contentious issue. Timing can be everything.

> > P.S. I hadn't looked at RFC 6589 before, and I  have to say I find its
> > standards-track status to be nothing short of astonishing. How on earth do
> > you assess interoperability?

> Maybe it's the ability to relate reports from the same source with one another
> which makes them manageable.  Producers of actionable reports and consumers who
> react properly can be said to interoperate, can't they?

Absent agreement on what gets redacted and how? Not even close.

RFC 6590 doesn't even pass muster as a BCP, since it describes an overall
approach to solving a range of problems and explictly does not recommend
a particular practice.

This is an informational document, nothing more and nothing less.

				Ned