Ale, Including that data in a DMARC report may not be very useful if it's going to the domain holder instead of the DKIM signer. For example, SES signs all of their messages, but unless that 5322 owner shares the data, they wouldn't see any information relating to those signatures.
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: Ietf-dkim <ietf-dkim-boun...@ietf.org> On Behalf Of Alessandro Vesely > Sent: Friday, September 15, 2023 5:29 AM > To: ietf-dkim@ietf.org > Subject: Re: [Ietf-dkim] Usage of RFC 6651 for replay-mitigation > interoperability > reporting (was Re: What makes this posting different from the original > posting?) > > On Sun 10/Sep/2023 18:44:00 +0200 Jesse Thompson wrote: > > On Fri, Sep 8, 2023, at 9:23 AM, Murray S. Kucherawy wrote: > >> On Fri, Sep 8, 2023 at 7:17 AM Jesse Thompson <z...@fastmail.com> > >> wrote:__ > >>>>> Is rfc6651 a lost cause? It looks like it defines a reporting mechanism > >>>>> in > control of the signer, as opposed to the attacker. > >>>> > >>>> Has anyone (else) implemented it? > >>> > >>> That's what I want to understand. Or, more specifically, if no one > implemented it, why? And have those blockers changed due to the changed > landscape with dkim replay, etc. > >> > >> When DKIM was young, a mechanism like the one defined in RFC 6651 was > enormously valuable to me when two implementations were trying to debug > interoperability problems. It allowed us to see why signatures were failing. > >> Once all the bugs were worked out and things like canonicalization and > common MTA mutations were well understood, the need for this sort of thing > faded away. > > > > DKIM Replay is leading to interoperability problems as result of local > > policies > being rolled out to mitigate the abuse, and senders (and their customers) > need to > make changes to their configuration to not get caught up in the emerging > algorithms. Examples may include duplicate message throttling, blind recipient > limitations, tighter expiration enforcement, etc. > > > > I think usage of the 'p' and 'x' reports and the 'rs' tag would be > > valuable (perhaps enormously, as you experienced first hand) > > > > p Reports are requested for signatures that are rejected for local > > policy reasons at the Verifier that are related to DKIM > > signature evaluation. > > > > x Reports are requested for signatures rejected by the Verifier > > because the expiration time has passed. > > > These look like aggregate data that could be included in DMARC reports or > extensions thereof. Perhaps that tool has more traction than 6651. > > > Best > Ale > -- > > > > > > > > > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf- > dkim__;!!CQl3mcHX2A!CxerxXN6Fi9wzANlOVjp2kI_Ez9FcMicLCLiN2yFF_BlGeekE > KXeoaz9OSMOGVYMO6TL336wKx3HWNHUS6c$ _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
