Subject: [dmarc-ietf] Clarification about data integrity within Aggregate Reports (Ticket #40)

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 30 Dec 2020 22:18:35 +0000

Hello folks,

There's an open ticket (https://trac.ietf.org/trac/dmarc/ticket/40) noting that we should clarify what constitutes valid data in a report. For example, the report cannot state that DMARC-DKIM was a "pass" when DKIM itself was a failure.  See the original thread here:

https://mailarchive.ietf.org/arch/msg/dmarc/Ii_dLXFzBNnRP361F922ty789I8/

It seems like the gist is that within the report it should never happen that DKIM or SPF are noted to have passed in the context of DMARC if they have not passed on their own.  It should also be properly noted by the reporter if they override with local policy.  Not by overriding the SPF/DKIM failures (and showing them as incorrectly passing), but instead by noting that local policy overrides properly (regardless of whether that override is higher or lower).

Does that seem properly summarized?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 31 Dec 2020 16:27:20 +0100

> Does that seem properly summarized?

If the aggregate report content, Section 2.2, was well explained, the above 
text would be redundant.  The point is that Section 2.2 looks like a high level 
list of features.  It is completely useless for implementing a report producer, 
let alone a consumer.  We have to rewrite that section, possibly trying to 
re-use the same wording and the same order of appearance of concepts, so as to 
minimize readers' confusion, but strictly matching the content of Appendix A 
(was Appendix C).

The consistency checks above can be useful for building verification tools.

Let me take this occasion to recall that there are XML syntax check tools that 
can be used to automatically verify the syntax based on the schema.  We should 
write a more compliant XML in order to use them.

Best
Ale
--