Roland, This is very helpful, thank you! I guess I assumed the issuance of forensic (failure) reports was more common than you indicate; because at my day job we get gobs of them for various domains where the DMARC reporting addresses were blindly pointed at us without any understanding of how to process. I haven't looked close enough to pick up on that they are probably not domains we're commonly familiar with (i.e. I assume this isn't the top 5 US webmail providers sending these). It's entirely possible that they're all edge case hobbyist domains off in faraway lands that won't generate useful info for anyone that isn't sending to bazillions of people. I will look into that. And it's time to start thinking about how to parse aggregate reports.
(What action do I plan to take WRT to failures -- none, assuming the issue is not mine to fix. Mostly looking to get a feel for the edge cases that break, like mailing lists.) Cheers, Al Iverson On Sun, May 27, 2018 at 10:30 PM Roland Turner via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > Al, > Note that the terminology changed a while back from forensic reports to failure reports, presumably to remove the confusion that the use of the term forensic invites[1]. > You've not stated what action you intend to take in response to the receipt of a failure report, so it's a little difficult to answer your question, but I'd point out two things: > Very few receiver-side authentication failures will cause you receive a failure report merely in response to your setting a ruf parameter. Receivers are in general unwilling to send them blindly, most will want background checks of the requester and a formal NDA, both of which generally happen as part of the contract with a specialist organisation providing email-authentication-related services. The spec provides for an interoperable failure reporting mechanism, but [obviously] can't mandate its use. If you are interested in knowing about failures in order to take some action (e.g. to change how you use particular lists, or to identify a list operator to encourage to change their DMARC handling), then >90% of the information that you're looking for is exclusively available to you in the aggregate reports. > For domains where you've not yet switched on p=reject, e.g. to minimise disruption of email flow, knowing about third parties impersonating you may be relevant whether or not they're sending to the few receivers who will send failure reports on request. This was certainly the case for me; when it became clear through aggregate reports that my personal domain was being impersonated - despite my not receiving a single failure report - I elected to switch on p=reject, then set about encouraging the few list operators who weren't yet honouring it to do so. > This does mean having to put in place some means to monitor aggregate reports for interesting failures, yes. Processing the XML to discover this is pretty straightforward, so long as you avoid the usual risks in processing XML from untrusted sources. > - Roland > 1: working out what happened before vs. suitability for presentation in a public forum, particularly a court of law > ________________________________ > On 28/05/18 01:17, Al Iverson via dmarc-discuss wrote: > Well, I think that would depend on the use case, would it not?. I've got > one server and Google Apps, everything signs with DKIM, and SPF is > configured correctly. I don't really have any edge cases to look out for -- > no other outsource service providers in the mix. The rare (for me) failed > message forensic reports provide feedback about other peoples' broken > mailing lists (and maybe someday examples of forgery, if somebody forges my > domain). In that scenario, I'm getting a daily "everything is OK" aggregate > report from Google and a few others that is of low value to me. I could > either set a filter to delete those reports, or I modify my DMARC record to > stop requesting them. Either way, this is reversible in the future. > For an ISP or corporate entity, I would be more inclined to agree with you. > Somebody in another department could set up with some other service > provider that handles some form of email messaging without enabling proper > authentication and you'd want to be able to catch that, and summary > (aggregate) information from the big guys would help immensely. > So I do get your point, but it doesn't see to fit my use case. > Cheers, > Al Iverson > On Sun, May 27, 2018 at 11:18 AM Vladimir Dubrovin <dubro...@corp.mail.ru> > wrote: > Aggregated report contain all information, including SPF/DKIM/DMARC > failures, but it doesn't contain forensic information (e.g. failed > message Subject). Aggregated reports are supported by almost all large > ESPs, so, if you have some troubles you will probably see it in > aggregated report. > Forensic report contains information about individual message failing > SPF/DKIM/DMARC with some details (forensic information) regarding this > message, e.g. message headers. The problem is there are very few peers > sending forensic reports, so you may receive some reports, but should > not expect to receive forensic reports in the case of failure. > If you do not receive aggregated reports there is a very high chance to > have configuration problem without noticing it. > 27.05.2018 17:43, Al Iverson via dmarc-discuss пишет: > In a DMARC record, I see that rua= specifies the address to which > aggregate > feedback is to be sent, and ruf= specifies the address to which > message-specific forensic information is to be reported. > I'm just a tiny bit confused about terminology-- could somebody confirm > for > me that I'm thinking of this correctly? I prefer only to receive failure > reports at this time. I don't want to receive summary reports telling me > that everything is AOK. That suggests to me that I should remove the rua > field but leave the ruf field. > Have I got that right? > Thanks, > Al Iverson > -- > Vladimir Dubrovin > @Mail.Ru > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html) -- al iverson // wombatmail // miami http://www.aliverson.com http://www.spamresource.com _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
