--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -----Original Message-----
> From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Alessandro Vesely
> Sent: Thursday, December 31, 2020 10:27 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Clarification about data integrity within Aggregate
> Reports (Ticket #40)
>
> On Wed 30/Dec/2020 23:18:35 +0100 Brotman, Alex wrote:
> > Hello folks,
> >
> > There's an open ticket
> (https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/40__;!
> !CQl3mcHX2A!VCWZO-
> 6THaYEt8r1yDE9TgQzeJyuFmGpwSepa3SWwao3ViUQfPaxJ5FrbnTPKuzHLj6b
> $ ) 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/dmar
> > c/Ii_dLXFzBNnRP361F922ty789I8/__;!!CQl3mcHX2A!VCWZO-
> 6THaYEt8r1yDE9TgQz
> > eJyuFmGpwSepa3SWwao3ViUQfPaxJ5FrbnTPKvlFgYhq$
> >
> > 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?
>
>
> 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).
>
I don't think I disagree here, but I want to be clear on what you're
requesting. You'd like to see a more verbose description of the goal of the
aggregate report, as well as the contents?
"... Each report MUST contain data for only one 5322 domain. The values
reported MUST be as evaluated from the original message, not from the local
policy overrides ..." and so on?
> 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.
I've written an RNC (Relax NG Compact) previously. As we get closer to
finalizing any format changes, we can create that, and then use jing/pyjing to
validate XML reports. You'd want to use this to enforce report contents as
specified above? Not that I'm opposed, though, it can't enforce that the
sender is using the proper values for DKIM pass/fail, only that the value is
one of "pass"/"fail" (at least for RNC). I don't believe there's a way to
create interrelated dependencies where we could say that "DMARC can't possibly
pass if both SPF and DKIM fail, and the report should be bogus if that's the
case".
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!VCWZO-
> 6THaYEt8r1yDE9TgQzeJyuFmGpwSepa3SWwao3ViUQfPaxJ5FrbnTPKvtKzeGr
> $
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
