Please, RUF is a ""Failure Report", not a "Forensic Report". Please read RFC 7489 - https://datatracker.ietf.org/doc/rfc7489/
On Sat, Jan 26, 2019 at 12:21 PM Дилян Палаузов <[email protected]> wrote: > Hello John, > > On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: > > In article <[email protected]> > you write: > > > How can a domain owner communicate, that its users agree to have > investigations on forensic reports, where DKIM > > > signatures failed (fot the purpose of avoiding repeating errors in > DKIM signing/validation)? In particular, that there > > > is no expectation of the users that a deleted message is erased and > that the domain owner, DNS staff and email staff > > > function good as whole? > > > This is way outside the scope of DMARC., however, the very fact that the domain has provided an email address for receiving RUF reports is a pretty reliable indicator. Presumably DNS and mailops staff work for/on behalf of the domain owner. > > I suppose they could try to put it in the terms of service, but I > > wouldn't begin to guess whether that would be enforcable or even legal > > in places with the GDPR and other privacy laws. > > > > More to the point, I wouldn't bother. The failure reports are almost > > entirely useless. Of the ones I get, the majority are random Chinese > > spam that happened to forge one of my domains on the From line, the > > rest are from mailing lists where I wouldn't expect DMARC to pass. > Clearing out the chaff originating from servers other than your own helps, but I'm not going to try to teach John anything. > > A domain owner can certainly clarify anything in the terms of service, but > even if the domain owner does these > clarifications, s/he will not receive DKIM/DMARC forensic reports, because > there is no mean to communicate to the > generators of those reports, that sending forensic reports violates users > expectations. > Individual user expectations are well outside the scope of DMARC. It is a domain/subdomain level protocol. If you don't want the reports then don't provide a destination for them to be delivered to. > > The reasons mentioned here against sending forensic reports were, that > this might not match user expectations (on > deleted information) and because email staff and DNS staff may differ. I > approached both concerns, by stating that user > expections can be put in Terms of Use and that a domain owner can decide, > that for a domain it is acceptable to receive > forensic reports and insert this infomation in the Terms of Use. So… what > else exactly needs to happen, to resolve the > concerns against sending forensic reports (which was my original question)? > > If GDPR is the only concern, this can also be clarified. But clarifying > that GDPR is not a problem, will be losing > time, if independent of it there are other concerns. > > Imagine there is a failure report stating that after a direct > communication between your server and another server, the > receiving server sends you an aggregate report, stating that 1% of the > messages you sent yesterday do not validate DKIM. > How do you suggest to proceed to reduce this to 0%? > Over time you are unlikely to keep "legitimate" failures at 0%. There are lots of moving parts and pieces that can cause a failure. It also depends on the characteristics of the mail streams involved. The domain owner(s) and staff will need to determine how much effort they are willing to put in eliminating (legitimate) email failures. If I'm sending 10 million emails to a domain and 1% are failing then I'm likely to look into it. On the other hand, if I'm sending 100 emails a day to a domain from an overall large system and 1% (1 email) is failing, that really falls into the noise and is unlikely to get much time spent on it. Michael Hammer
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
