Subject: [dmarc-ietf] Clarification of Subdomain Reporting

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 11 Dec 2020 18:36:16 +0000

Based on a discussion from last year (https://mailarchive.ietf.org/arch/msg/dmarc/YoHhhaAfwRjbd8aq4fiV6xU1ifw/), there was a request/ticket to clarify the language in the document.

>From https://tools.ietf.org/html/rfc7489#section-7.2:

 *  Data for each Domain Owner's subdomain separately from mail from
      the sender's Organizational Domain, even if there is no explicit
      subdomain policy

Seems to be lacking clarity.  I took an initial attempt at clarifying that bullet, but welcome comments:

*  Within the same report, subdomain data should be separate from
   data for the Sender's Organizational Domain.  This should be
   true even when subdomain does not have their own explicit DMARC
   record

Does that seem reasonable?  I'd suspect we should modify the sample report to include a subdomain as well.

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

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2020 14:38:44 -0500

In article <[email-masked]> you write:
>Based on a discussion from last year
>(https://mailarchive.ietf.org/arch/msg/dmarc/YoHhhaAfwRjbd8aq4fiV6xU1ifw/), there was a
>request/ticket to clarify the language in the document.
>

That would be a change to the XML report schema. It'd change as I show
below to force a separate row for each header_from.

That's a somewhat incompatible change, so I'd want to be sure we agree
that it's a real problem that's worth changing the report format. I
suppose if we do we should encourage report consumers to be prepared
for old and new formats.

R's,
John

   <xs:complexType name="IdentifierType">
     <xs:all>
       <!-- The envelope recipient domain. -->
       <xs:element name="envelope_to" type="xs:string"
                   minOccurs="0"/>
       <!-- The RFC5321.MailFrom domain. -->
       <xs:element name="envelope_from" type="xs:string"
                   minOccurs="1"/>
Old:
       <!-- The RFC5322.From domain. -->
       <xs:element name="header_from" type="xs:string"
                   minOccurs="1"/>

New:
       <!-- The RFC5322.From domain. -->
       <xs:element name="header_from" type="xs:string"/>

     </xs:all>
   </xs:complexType>

---

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 11 Dec 2020 21:23:15 +0000

> -----Original Message-----
> From: John Levine <[email-masked]>
> Sent: Friday, December 11, 2020 2:39 PM
> To: [email-masked]
> Cc: Brotman, Alex <[email-masked]>
> Subject: [EXTERNAL] Re: [dmarc-ietf] Clarification of Subdomain Reporting
>
> In article
> <[email-masked]
> 11.prod.outlook.com> you write:
> >(https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/dmar
> >c/YoHhhaAfwRjbd8aq4fiV6xU1ifw/__;!!CQl3mcHX2A!WeJ2k0NWH5mMH3xZ4
> m50qgan4LKX-1dJkG9EIbOpAQShq9B1mQP7uwFLByCaECBQ7Ypo$ ), there was
> a request/ticket to clarify the language in the document.
> >
> >>From
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc7489*section-
> 7.2__;Iw!!CQl3mcHX2A!WeJ2k0NWH5mMH3xZ4m50qgan4LKX-
> 1dJkG9EIbOpAQShq9B1mQP7uwFLByCaEErMUwqg$ :
> >
> That would be a change to the XML report schema. It'd change as I show below
> to force a separate row for each header_from.
>
> That's a somewhat incompatible change, so I'd want to be sure we agree that
> it's a real problem that's worth changing the report format. I suppose if we do
> we should encourage report consumers to be prepared for old and new formats.

The goal was to clarify the language, without (to the best of our ability) changing the schema.  I'd welcome a other attempts at clarifications (if you believe mine introduces structural XML changes).

---

From: "John R Levine" <[email-masked]>
Date: 11 Dec 2020 16:34:20 -0500

> The goal was to clarify the language, without (to the best of our ability) changing the schema.  I'd welcome a other attempts at clarifications (if you believe mine introduces structural XML change…

So it'd say yeah, we know the XML lets you put multiple header_from 
domains in the same report row, but please don't do that, send a separate 
report row for each header_from?

I suppose that could work.

R's,
John

>>        <xs:element name="header_from" type="xs:string"/>

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 12 Dec 2020 11:52:28 +0100

> below to force a separate row for each header_from.

Maybe it's me, but I don't understand the change below.  The only difference I 
see between Old: and New: is the removal of «minOccurs="1"».  Since that is the 
default value, I see no incompatibility.  What am I missing?

BTW, I passionately hope we're going to change the schema anyway (selector, 
version, ...)

Best
Ale

---

From: "John Levine" <[email-masked]>
Date: 12 Dec 2020 13:56:58 -0500

>default value, I see no incompatibility.  What am I missing?

If there is neither minOccurs nor maxOccurs, the field occurs exactly once.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 14 Dec 2020 11:00:29 +0100

> If there is neither minOccurs nor maxOccurs, the field occurs exactly once.

I agree that specifying «minOccurs="1"» is redundant and could be avoided.

Best
Ale

-- 
http://www.chrismadden.co.uk/cartoon-gallery/occams-razor-ockhams-razor-too-complicated/

---

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 14 Dec 2020 15:57:53 +0000

> From: John R Levine <[email-masked]>
> Sent: Friday, December 11, 2020 4:34 PM
> To: Brotman, Alex <[email-masked]>; [email-masked]
> Subject: RE: [EXTERNAL] Re: [dmarc-ietf] Clarification of Subdomain
> Reporting
>
> >> That's a somewhat incompatible change, so I'd want to be sure we
> >> agree that it's a real problem that's worth changing the report
> >> format. I suppose if we do we should encourage report consumers to be
> prepared for old and new formats.
> >
> > The goal was to clarify the language, without (to the best of our ability)
> changing the schema.  I'd welcome a other attempts at clarifications (if you
> believe mine introduces structural XML changes).
>

So it should be clarified as such:

   o  Data for each Domain Owner's subdomain separately from mail from
      the sender's Organizational Domain, even if there is no explicit
      subdomain policy

Perhaps changed to something more like:

  o A separate report should be generated for each 5322.From subdomain, regardless
      of which policy domain was used during receipt of messages

For the other thread with Ale, is there anything wrong with stating both minOccurs/maxOccurs set at "1" so that it's more clear that it must be once, and only once?

> Please consider the environment before reading this e-mail.
> https://urldefense.com/v3/__https://jl.ly__;!!CQl3mcHX2A!UPJ_XPLNAqIcy
> 2hcn14oeuebDZfD_i2QOE4Z0FhOoQemEIHEyov_kFTxybH4FE6WvlDw$

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 15 Dec 2020 09:58:00 +0100

>> report row for each header_from?

I'm still not clear how could two From: domain fall in the same row.  Appendix 
C is very clear that there is a single IdentifierType for each row.  And each 
IdentifierType has exactly one "header_from".  I am appalled at the fact that 
such rule is not given in the text.  There has to be a better description in 
Section 2.2.  I'd propose something like:

     The bulk of a report consists of data for each message received during the
     reporting period, where each record aggregates messages having similar
     characteristics.  Relevant characteristics are:

Then follow with a revised bullet list.  It should be a descriptive equivalent 
of the grammar in Appendix C.  The current version doesn't match, obviously, 
since it confuses ourselves.  We cannot ship it as is.

>        of which policy domain was used during receipt of messages

That's excessive, IMHO.  If the recipient is the same, there's no reason to 
split that data into different reports.

> For the other thread with Ale, is there anything wrong with stating both minOccurs/maxOccurs set at "1" so that it's more clear that it must be once, and only once?

At the beginning of Appendix C there is a paragraph saying:

    NOTE: Per the definition of XML, unless otherwise specified in the
    schema below, the minOccurs and maxOccurs values for each element are
    set to 1.

It's hard to make it clearer than that.  Perhaps:

    NOTE: Per the definition of XML, each element can appear zero or more
    times, as specified by minOccurs and maxOccurs values.  When not
    explicitly specified, the default value for both attributes is 1.

After that, specifying the default might be more confusing than helpful.

Best
Ale
--