On Wed, Oct 29, 2025 at 11:22 AM Alessandro Vesely <[email protected]> wrote:

> The points I quote below below seem to depend on an interpretation of fo=,
> which took me quite quite a while to understand.


That's not a good sign ...


> > 5. In Section 2, replace Paragraph 4 with:
> >
> >     When a Domain Owner requests failure reports for the purpose of
> >     forensic analysis, and the Mail Receiver is willing to provide such
> >     reports, the Mail Receiver generates and sends a message using the
> >     format described in [RFC6591] but as modified in Section 4 of this
> >     document.
>
> The Mail Receiver may want to generate a DKIM report, possibly after
> reading fo=d.  In this case, the modifications in Section 4 should be
> ignored.  Instead, they should use the ARF extension defined in RFC 6591
> only.
>
> If this interpretation is correct, citing RFCs 6651/2 is incorrect.  These
> documents specify how to /request/ DKIM or SPF failure reports, not their
> format.


They do stipulate that the format to be used is the ARF format.

> 8. Also in Section 3, some explanation of why that RECOMMENDED is there
> > would be good to include (or remove it if we can't justify it in terms
> of
> > interoperability).
>
> The main reason is that the methods defined in RFCs 6651/2 are almost
> never used.  Their use is considered an error by most DKIM/ SPF syntax
> checkers.


The sentence we're talking about is:

"Report Consumers are RECOMMENDED to consolidate their requirements into a
single DMARC Policy Record."

What this is telling me (I think) is that it's a really good idea for
interoperability or security for sending domains to make a request for
DMARC failure reports and not to request DKIM or SPF reports.  It doesn't
tell me why, and doesn't say anything about RFC 6651/6652 being not
preferred by contemporary operators, or why that might be.

I think if those RFCs have just fallen into disuse, then this RECOMMENDED
is misplaced; we don't need to force that point if the market has already
made that determination.  I also think that someone choosing to deviate
from that advice and use everything doesn't cripple the protocol or its
interoperability.


> Almost all the other points look fine.  I saved changes on GitHub; see
>
> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/compare/2ac4ec04f49bf08c3948e8a0bafa40e65e4f4bdf...main


Those look good, except for the "Mail eXchanger" bit, which I covered
elsewhere.

-MSK
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to