Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

From: [email-masked]
Date: Wed, 18 Aug 2021 13:22:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF.

        Title           : DMARC Aggregate Reporting
        Author          : Alex Brotman
	Filename        : draft-ietf-dmarc-aggregate-reporting-03.txt
	Pages           : 24
	Date            : 2021-08-18

Abstract:
   DMARC allows for domain holders to request aggregate reports from
   receivers.  This report is an XML document, and contains extensible
   elements that allow for other types of data to be specified later.
   The aggregate reports can be submitted to the domain holder's
   specified destination as supported by the receiver.

   This document (along with others) obsoletes RFC7489.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-aggregate-reporting-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 18 Aug 2021 20:30:06 +0000

Hello folks,

My updates aren't as exciting as they are for the other document.  I wanted to get a document out with the feedback provided.  Tried to clean up the extensions section, some normative language, and a few other items.  If you feel as though something is amiss, or I've misinterpreted the consensus, please let me know.

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

> -----Original Message-----
> From: dmarc <[email-masked]> On Behalf Of internet-
> [email-masked]
> Sent: Wednesday, August 18, 2021 4:22 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt
>
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-
> dmarc-aggregate-reporting/__;!!CQl3mcHX2A!V4dyBOdtyfUCLKNx-
> DTfL0s53LkzELz3txXwSw3FHpD4FjlCsCR--yZnIFIPT65dsNWz$
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> ietf-dmarc-aggregate-reporting-03__;!!CQl3mcHX2A!V4dyBOdtyfUCLKNx-
> DTfL0s53LkzELz3txXwSw3FHpD4FjlCsCR--yZnIFIPT8P4Kaj1$
>
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-
> dmarc-aggregate-reporting-03__;!!CQl3mcHX2A!V4dyBOdtyfUCLKNx-
> DTfL0s53LkzELz3txXwSw3FHpD4FjlCsCR--yZnIFIPT8GeqF4e$
>
>
> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-
> drafts/__;!!CQl3mcHX2A!V4dyBOdtyfUCLKNx-
> DTfL0s53LkzELz3txXwSw3FHpD4FjlCsCR--yZnIFIPT3PaCn_l$
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!V4dyBOdtyfUCLKNx-
> DTfL0s53LkzELz3txXwSw3FHpD4FjlCsCR--yZnIFIPT5u086-R$

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 19 Aug 2021 13:18:34 +0200

On Wed 18/Aug/2021 22:30:06 +0200 Brotman, Alex wrote:
> If you feel as though something is amiss, or I've misinterpreted the consensus, please let me know.

I'd swap SHOULD and MUST between the following sentences:

     If a report generator needs to re-send a report, the system
     SHOULD use the same filename as the original report.

and

     The RFC5322.Subject field for individual report submissions
     MUST conform to the following ABNF:

For the subject, alternatively, "Report-Id" msg-id could be optional, 
as it is with the filename.  It is very noisy and doesn't seem to be 
much useful if it doesn't match the filename, let alone its uniqueness.

Best
Ale
--

---

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 26 Aug 2021 14:37:27 +0000

I haven't heard any other support for this.  I'm inclined to leave it as is currently written unless others chime in.

> From: dmarc <[email-masked]> On Behalf Of Alessandro Vesely
> Sent: Thursday, August 19, 2021 7:19 AM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-
> 03.txt
>
> For the subject, alternatively, "Report-Id" msg-id could be optional, as it is
> with the filename.  It is very noisy and doesn't seem to be much useful if it
> doesn't match the filename, let alone its uniqueness.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> __;!!CQl3mcHX2A!WUcDqYdgg-
> N4xaJrhTrh7yyVJXLl0YFs7Q9H9vY338oILvyM7_trujnFdTtnE_fQ2W9b$

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Aug 2021 07:47:38 -0700

>      SHOULD use the same filename as the original report.

Why is this only SHOULD?  What legitimate reason might an implementation
have for deviating from this advice?

> much useful if it doesn't match the filename, let alone its uniqueness.

If there's information being encoded in the Subject field that the
recipient is expected to be able to decode, I think this makes sense.  If
it's just a "it sure would be nice" sort of deal, then I don't even think
this should even be a SHOULD.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 26 Aug 2021 15:41:17 +0000

>have for deviating from this advice?

I've reviewed the draft and I agree.  Particularly given the guidance on how to name the files: "filename MUST be constructed using the following ABNF ...".

>this should even be a SHOULD.

I think the current draft has some inconsistency about retransmission and deduplication that needs to be addressed.  

In this same section it says, "The purpose of the Report-ID: portion of the field is to enable the Domain Owner to identify and ignore duplicate reports that might be sent by a Mail Receiver." In the filename section, right after the bit quoted above, it also says, "This would allow the receiver to overwrite the data from the original, or discard second instance of the report."

Why would a report be sent more than once?  Other than error cases, the only thing I can immediately think of is the case where the report was sent, but the SMTP session doesn't properly terminate so it's unknown if they entire report was received.

Which leaves me wondering what the receive side processing should be?

Should partial reports be discarded? (draft is silent on this)

If a complete message has been received, then I think deduplicating based on the Report-ID makes sense (don't have to open up the MIME parts to do it).

It's not clear to me from skimming the draft if one message can have multiple XML files or not (I'm less familiar with the details of the feedback part of DMARC).  If there can be only one, that's probably sufficient.  If there can be more than one, then there may be a case where one file was successfully received and stored, but another wasn't.  In this case, you would need to examine the MIME parts, so filename consistency would be important.

I suspect that is more questions than answers, but I definitely agree with MSK that more work is needed here.

Scott K

---

From: Matthäus Wander <[email-masked]>
Date: Fri, 27 Aug 2021 11:44:07 +0200

>      SHOULD use the same filename as the original report.

The paragraph is justified by deduplication:

    If a report generator needs to re-send a report, the system SHOULD
    use the same filename as the original report.  This would allow the
    receiver to overwrite the data from the original, or discard second
    instance of the report.

But this works only if the sender ensures to leave the filename 
unchanged. So it's either a MUST or the paragraph can be omitted altogether.

> For the subject, alternatively, "Report-Id" msg-id could be optional, as 
> it is with the filename.  It is very noisy and doesn't seem to be much 
> useful if it doesn't match the filename, let alone its uniqueness.

The Report-ID is also justified by deduplication:

    The purpose of the Report-ID: portion of the field is to enable the
    Domain Owner to identify and ignore duplicate reports that might be
    sent by a Mail Receiver.

1. So Report-ID is either a MUST to allow deduplication,
2. or Report-ID is not required for deduplication,
(In the filename it's optional, but the filename has a mandatory time 
range, which the subject has not. Deduplication requires one of these 
two information. You might use the RFC5322.Date, but this introduces 
another dependency.)
3. or deduplication via subject is not supposed to be supported.
Is there another use case for a formal ABNF spec of the subject?

Regards,
Matt

---

From: Matthäus Wander <[email-masked]>
Date: Fri, 27 Aug 2021 12:09:51 +0200

Scott Kitterman wrote on 2021-08-26 17:41:
> Why would a report be sent more than once?

Happens regularly with Google as reporter. Seems to be a design choice.

> Other than error cases, the only thing I can immediately think of is the case where the report was sent, but the SMTP session doesn't properly terminate so it's unknown if they entire report was received.
> 

> Should partial reports be discarded? (draft is silent on this)

CRC would break with compressed files in this case, i.e. the report 
would be clearly invalid.

If the reporter generates a partial report but with valid syntax, then 
the report consumer will have no way to detect it. Re-sending the full 
report may fix the issue (if the consumer implements an overwrite logic) 
or make it worse (if the consumer doesn't deduplicate).

> If a complete message has been received, then I think deduplicating based on the Report-ID makes sense (don't have to open up the MIME parts to do it).

Yes.

> It's not clear to me from skimming the draft if one message can have multiple XML files or not (I'm less familiar with the details of the feedback part of DMARC).  If there can be only one, that's…

The definition of one Report-ID in the subject line implies that a 
message carries no more than one report. This could be clarified in the 
RFC, though.

Regards,
Matt