Re: [dmarc-ietf] Time to work on failure reporting

[Alessandro Vesely <[e-mail]>]

Hi,
I re-read the I-D and applied some more substantive changes.

I added an Identity-Alignment: line to the example, and changed back the Auth-Failure: to "dmarc".

I added DKIM-Domain, DKIM-Identity, DKIM-Selector to the example, as required by the spec.  I'd drop that requirement.  In the example there are _two_ (failed) signatures by the aligned domain, but these fields have Multiple Appearances: No.  So it's not clear what should be included.  The spec says:

                      Note that a failure report generator MAY also
        independently produce an AFRF message for any or all of the
        underlying authentication methods.

It would make more sense to add multiple message/feedback-report entities in the same report.  Shall we update RFC 5965 in that sense?


I didn't add an SPF-DNS field, but tweaked the requirement instead.


Apart from the example, I commented out the suggestion to "only send a report to the first recipient of multi-recipient messages", as it seems to conflict with the requirement of making an attempt to deliver to each recipient, stated a couple of paragraphs above.

Instead, I added a line on debug messages.  Let's discuss it.

The I-D has no IANA Consideration section.  Identity-Alignment: is registered at IANA[*] referencing RFC 7489.  Since we're obsoleting it, I added a section to hijack that reference.

The "dmarc" parameter appears nowhere in that IANA page[*].  I added a section to create a new registry for the keywords allowed there.  Is that ok?


IANA Considerations:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/blob/main/draft-ietf-dmarc-failure-reporting-04.txt#L285

Example:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/blob/main/draft-ietf-dmarc-failure-reporting-04.txt#L663

This time I attach the diff.


On Sun 14/Aug/2022 16:58:02 +0200 John R Levine wrote:
>>> It does, it looks like someone did a quick cut and paste to make the 
>>> markdown.  But it's not that long, you're the editor, how about fixing the 
>>> md so it's useful for editing?
>>
>> It must have been me.  I recalled; I searched again for something to generate 
>> the md and again found only https://codebeautify.org/html-to-markdown.  That 
>> way the (bottom) part of the md looks similar to the txt, but it's not usable 
>> for editing.
>>
>> I'll fix it next time...
> 
> How about if you fix the markdown so it has the current contents of the draft, 
> and you add a Makefile that can turn the markdown into XML and the XML into 
> text and HTML one can look at.  You can use the markdown and makefile in the 
> dmarcbis repo as models.  Then push it to github and post an updated draft.


Hm... I'd start by posting the updated draft.  It'd probably take me some days to learn how to obtain the same XML file starting from a markdown one rather than editing it directly.  As the existing draft expires on the 21st, I'd revert the order of operations.


Best
Ale
-- 


[*] https://www.iana.org/assignments/marf-parameters/marf-parameters.xhtml