On Sun, Aug 24, 2025 at 10:43 AM Alessandro Vesely <[email protected]> wrote:
> > 7. Privacy Considerations > > [...] > > > > Given these factors, many large-scale providers limit or entirely > disable the > > generation of failure reports, preferring to rely on aggregate reports, > which > > provide statistical visibility without exposing sensitive content. > Operators > > that choose to enable failure reporting are strongly encouraged to: > > 1. Privacy considerations apply not only to the generation, but also to > the > consumption of failure reports. > What privacy concern is created by consuming a failure report? > 2. Perhaps we can say we /recommend limiting or entirely disabling/. The > wording of the paragraph doesn't make it clear whether the recommendation > is > directed only at large-scale providers or whether we're recommending to > behave > as large-scale providers do. Would we dare a SHOULD NOT unless they know > what > they're doing? > I don't think a recommendation has been put forward, or has to be. The goal of the section could be simply to enable operators to make an informed decision. I would shy away from BCP 14 language in this context. > 3. I'm not sure a comparison with aggregate reports is significant here. > > > Moreover, some implementers and consumers of failure reports have > attempted to > > use them for purposes such as deep threat hunting, malware inspection, > or > > content analysis. While technically feasible, such uses exceed the scope > of > > DMARC’s reporting intent and amplify privacy exposure by treating user > > communications as telemetry data. DMARC reporting is designed for > > authentication failure diagnostics, not for generalized message content > analysis. > > Isn't threat analysis one of the purposes of failure reports? > Was it? I don't think that was the original goal. -MSK
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
