Alessandro Vesely wrote on 2021-08-19 13:18:
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.
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.
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.
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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc