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

[Matthäus Wander <[e-mail]>]

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