In some offline discussions, there are two clarifications: 1) Todd points out that redacting DMARC report information would be pretty useful to spammers and phishers. So let's drop that idea. 2) Richard points out that the "feedback" and "feedhere" flags are for a feedback loop mechanism unrelated to DMARC reports. In that case, this proposes a new "dmarcreport" flag that notifies receivers that DMARC reports are requested. -Wei
On Wed, Nov 11, 2026 at 12:41 PM Wei Chuang <[email protected]> wrote: > Hi, > > We need a way to get feedback for new algorithms bring-up and understand > deliverability with DKIM2. This proposes modifying RFC9990 DMARC reports > to support DKIM2 to leverage the existing DMARC reporting infrastructure. > Multiple DKIM2 signatures can be supported very similarly to DKIM > multisignatures. Another alternative is to create a new DKIM report > standard but this risks losing support of the existing base of DMARC report > senders. Further the ability to get reports from intermediaries exists in > the unexplored DKIM2 spec "feedback" and "feedhere" flags that we examine > later. > > Let's look at a forwarding example with multiple signatures at the > originator: > > From: [email protected] > > DKIM2-Signature: i=1; d=sender.example; > s=rsa.sel:rsa-sha256:rsa+sig,mldsa44.sel:mldsa44:mldsa+sig|ed25519.sel:ed25519-sha256:ed25519+sig > > DKIM2-Signature: i=2; d=forwarder.example; s=rsa.sel:rsa-sha256:rsa+sig > > Below is a snippet of the proposed DMARC report for DKIM2 that is sent to > the originator sender.example. As noted in the "DKIM2 / DMARC Sender > Policy Proposal" thread, the originator i.e. message author by default gets > a DMARC report. We see the multiple signature results designated by the > selectors "rsa.sel" and "mldsa44.sel" from signatures created by the > originator. Note that the "ed25519.sel" was not evaluated as that was > short circuited. (This is a strawman to see if that's the right evaluation > with "any" behavior i.e. '|'. Happy to see what feedback there is about > the short circuit idea) You can see that both the originator's and > forwarder's results are presented, though it's possible that the receiver > may choose to reduce the scope of the results > > record: { > > row: { > > Source_ip: "127.0.0.1" > > Count: 1 > > ... > > } > > identifiers: { > > Header_from: "forwarder.example" > > } > > auth_results: { > > dkim2: { > > Domain: "sender.example" > > Result: "pass" > > Selector: "rsa.sel" > > } > > dkim2: { > > Domain: "sender.example" > > Result: "pass" > > Selector: "mldsa44.sel" > > } > > dkim2: { > > Domain: "forwarder.example" > > Result: "pass" > > Selector: "rsa.sel" > > } > > spf: { > > Domain: "forwarder.example" > > Result: "pass" > > } > > } > > } > > DKIM2 spec also has "feedback" and "feedhere" flags. This proposes that > forwarders who have "feedback" flag may get the DMARC reports. If so, the > receiver looks up the DMARC policy corresponding to the "d=" domain and > send reports to the "rua" and "ruf" addresses. "feedback" here provides a > privacy sensitive bounce. It can also be used as a privacy signal to > indicate the DMARC report redaction of the results of that domain that > would otherwise be sent to other domains. > > This example illustrates "feedback" and "feedhere" flags where the > forwarder requests DMARC reports. > > From: [email protected] > > DKIM2-Signature: i=1; d=sender.example; > s=rsa.sel:rsa-sha256:rsa+sig,mldsa44.sel:mldsa44:mldsa+sig|ed25519.sel:ed25519-sha256:ed25519+sig; > f=feedhere > > DKIM2-Signature: i=2; d=forwarder.example; s=rsa.sel:rsa-sha256:rsa+sig; > f=feedback > > A DMARC report can be sent to forwarder.example,but it is filtered to > excludes results from sender.example that have the feedhere flag. > > record: { > > row: { > > Source_ip: "127.0.0.1" > > Count: 1 > > ... > > } > > identifiers: { > > Header_from: "forwarder.example" > > } > > auth_results: { > > dkim2: { > > Domain: "forwarder.example" > > Result: "pass" > > Selector: "rsa.sel" > > } > > spf: { > > Domain: "forwarder.example" > > Result: "pass" > > } > > } > > } > > > -Wei > >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
