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

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 1 Sep 2021 12:34:52 +0000

It feels like folks would prefer that the subject be required to be of a specific format to better enable duplicate report processing.  Do I understand that correctly?

So that would be:

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

And:

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

And we need to add some language suggesting how to deal with duplicates report transmission, if they happen.  Scott/Matt also pointed toward a few other areas that could use with a bit of clarification.

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

> -----Original Message-----
> From: dmarc <[email-masked]> On Behalf Of Matthäus Wander
> Sent: Friday, August 27, 2021 6:10 AM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-
> 03.txt
>
> 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.
> >
> > Which leaves me wondering what the receive side processing should be?
>
> > 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 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.
>
> 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
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!VARGCtFK2D3DtJLxI2cq5iDvCCraX74A2LhFHQst6COZ1K187
> _UjKv583lD5kM8thacb$

---

From: "John Levine" <[email-masked]>
Date: 1 Sep 2021 16:28:46 -0400

>     MUST conform to the following ABNF:

Sounds right.

>And we need to add some language suggesting how to deal with duplicates report transmission, if they happen.  Scott/Matt also pointed toward a
>few other areas that could use with a bit of clarification.

I don't see what the problem is with receiving duplicates.  Maybe you ignore them,
maybe you process them and replace the original result.  Either is OK.  Even if
you store the results twice, it's hard to see how that will make much difference
to your overall report analysis.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Sep 2021 20:35:43 +0000

>to your overall report analysis.

As long as the file name is the same, I agree.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 2 Sep 2021 11:21:03 +0200

>       MUST use the same filename as the original report.

Right.  That makes it easier to recognize duplicates.

>       MUST conform to the following ABNF:

The filename is defined like so:

     filename = receiver "!" policy-domain "!" begin-timestamp
                "!" end-timestamp [ "!" unique-id ] "." extension

So one may ask why the unique-id is optional in the filename while msg-id is 
mandatory in the Subject:?

     dmarc-subject = %x52.65.70.6f.72.74 1*FWS       ; "Report"
                     %x44.6f.6d.61.69.6e.3a 1*FWS    ; "Domain:"
                     domain-name 1*FWS               ; from RFC 6376
                     %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
                     1*FWS domain-name 1*FWS
                     %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
                     msg-id                          ; from RFC 5322

To answer that question, we need to establish what is the purpose of 
standardizing the Subject: line in aggregate reports, as it seems to duplicate 
the information already present elsewhere.  There are two difference between 
Subject: and filename:

1.  Subject: is a header field while filename is only a parameter.  As such, it 
is subject to RFC 2231 encoding, which some applications have difficulties with.

2.  Subject is prominently displayed by email clients.

What do we target, ease of scripting or readability?  For the former, we'd be 
better off defining a new header field and specifying how to encode it in case 
of IDNs.  Why is it domain-name here and policy-domain there?  And why does 
domain-name mention RFC 6376 and not RFC 8616?

If we target readability, instead, msg-id is just clutter.  It's unreadable, 
its relation with the unique-id is not specified, and the Message-ID: is a 1st 
class header field, so what is the reason to repeat its value, often longer 
than what the displayed Subject: can fit?

BTW, the relation between the unique-id of the filename and the report_id 
inside the XML is not specified too.  In the reports I send and in some of the 
ones I receive those three IDs coincide, but perhaps the spec should say 
something about that, shouldn't it?

Best
Ale
--