Only about redaction here. I'll wait for WG responses on the other points.
On Tue 21/Oct/2025 20:02:22 +0200 Todd Herr wrote:
On Tue, Oct 21, 2025 at 12:50 PM Alessandro Vesely <[email protected]> wrote:
On Tue 21/Oct/2025 00:31:43 +0200 Todd Herr wrote:
[,,,]
I'm confused by the Example Failure Report (Appendix A) in two respects:
1. There is no redaction in the example, not even of the To: address
Setting up a consistent redaction, as required by RFC 6590, is not trivial.
For example, it's unclear whether the local-part of the recipient's email
address should also be obscured in general places, i.e., not in an addr-spec.
In fact, many spam messages begin with "Dear local-part," so if you don't
obscure it there you can allow it to be inferred. OTOH, a local-part which is
also a word in the message language can appear in a sentence in the message
body, where it can be deduced if it's obscured.
Without redaction, the example is much more straightforward.
Fair enough. I know redaction is difficult, but I also guess that the
lawyers who might decide whether or not a Receiver will generate Failure
Reports are likely to blanche at any example that would show a recipient's
PII.
We might note this in the comment following the example (after the paragraph
"The Source-Port field definition..."). For example, like so:
In the final MIME entity, the local-part of To and From addresses is
reported unredacted. Since we know that local parts are PII, we could
reduce the privacy risk of reporting by redacting them. For example,
the report generator could have replaced "users" with "lRLxexey" and
"author" with "RT47aVey" throughout the entity.
Best
Ale
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
