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]
