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

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 <dmarc-bounces@ietf.org> On Behalf Of Matthäus Wander
> Sent: Friday, August 27, 2021 6:10 AM
> To: dmarc@ietf.org
> 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
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!VARGCtFK2D3DtJLxI2cq5iDvCCraX74A2LhFHQst6COZ1K187
> _UjKv583lD5kM8thacb$