On August 26, 2021 2:47:38 PM UTC, "Murray S. Kucherawy" <superu...@gmail.com>
wrote:
>On Thu, Aug 19, 2021 at 4:19 AM Alessandro Vesely <ves...@tana.it> wrote:
>
>> On Wed 18/Aug/2021 22:30:06 +0200 Brotman, Alex wrote:
>> > If you feel as though something is amiss, or I've misinterpreted the
>> consensus, please let me know.
>>
>>
>> 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.
>>
>
>Why is this only SHOULD? What legitimate reason might an implementation
>have for deviating from this advice?
I've reviewed the draft and I agree. Particularly given the guidance on how to
name the files: "filename MUST be constructed using the following ABNF ...".
>
> 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.
>>
>
>If there's information being encoded in the Subject field that the
>recipient is expected to be able to decode, I think this makes sense. If
>it's just a "it sure would be nice" sort of deal, then I don't even think
>this should even be a SHOULD.
I think the current draft has some inconsistency about retransmission and
deduplication that needs to be addressed.
In this same section it says, "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." In the filename section, right after
the bit quoted above, it also says, "This would allow the receiver to overwrite
the data from the original, or discard second instance of the report."
Why would a report be sent more than once? 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)
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).
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.
I suspect that is more questions than answers, but I definitely agree with MSK
that more work is needed here.
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
