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-boun...@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$ _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc