On Wed 17/Aug/2022 07:20:02 +0200 Neil Anuskiewicz wrote:
On Aug 9, 2022, at 3:17 AM, Ken O'Driscoll wrote:
Any hint about why it's not used?
PII. Report generators are reluctant to send reports that may contain PII for
compliance, security, and privacy reasons
Most receivers don’t provide failure reports but sometimes failure reports
(when available) can be useful.
What can they be useful for? Possible answers (my guessing):
* A large, complicated organization can find out which machine/ job is
producing bad authentication. (Why cannot this be found in aggregate reports?)
* A developer can find out which details of a signature didn't match. (This
requires full details, though.)
I realize there are privacy and regulatory concerns. Would it be possible to
reduce the scope of the failure report in general to address the privacy
concerns so that they’re more widely implemented?
One way could be to only report messages that were purposely sent for
debugging. The sender of a debug message would be supposed to not put
sensitive data in it.
The trade offs might be worth it to have a stripped down failure report if
there was a way to do it so the failure report would be useful but not
intrusive?
The problem is to know what data is useful. Signature checking may need
canonicalized header or body, which leaves almost no room for redaction.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
