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
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
