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

[Alessandro Vesely <[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:

    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.


> 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?


Best
Ale
--