In the -06 <https://datatracker.ietf.org/doc/html/draft-clayton-dkim2-spec-06> draft, the validation outputs are defined in section 11.1 <https://datatracker.ietf.org/doc/html/draft-clayton-dkim2-spec-06#section-11.1> as SUCCESS, PERMFAIL and TEMPFAIL. First I wonder, if the status can be aligned with RFC8601 <https://datatracker.ietf.org/doc/html/rfc8601>? Second, if so, can we define them with a sense of what that means for DKIM2 protections, particularly against replay? The prior email proposes DKIM1 → DKIM2 interop which complicates matters because DKIM1 interop can introduce replay vulnerabilities. That said, local policy may verify against replay. This proposal requires the forwarder to find the local-policy result equivalent to the -06 <https://datatracker.ietf.org/doc/html/draft-clayton-dkim2-spec-06> validation procedure result before permitting interoperability.
NONE: not DKIM2 signed PASS: a successful verification following procedures in the draft-clayton-dkim2-spec (or local-policy that provides a similar level of replay-protection). FAIL: signature verification failure, or "chain of custody" validation failure (or local-policy equivalent failure) PERMERROR: a permanent, non-recoverable error such as a missing expected header TEMPERROR: a temporary, recoverable error such as a DNS query timeout thanks, -Wei On Wed, Jan 21, 2026 at 12:47 PM Wei Chuang <[email protected]> wrote: > When DKIM2 is first deployed, we would expect that there will be a mix of > DKIM1-only and DKIM2-capable participants and expect that there will be > significant interaction between these two groups. We might also expect > that DKIM2-capable participants will likely sign and verify DKIM1 as before > to maximize compatibility with the DKIM1 world. An important question is > if and when we should add DKIM2 to a message that was originated at a > DKIM1-only sender, or when a message left DKIM2 to DKIM1 and returned > back. With the former i.e. DKIM1 → DKIM2, I suspect it does make sense > to support forwarding onwards to DKIM2 i.e. DKIM1 → DKIM2 → DKIM2. The > messages originate at DKIM1-only then sent to a DKIM2-capable forwarder, > and then resent to another DKIM2-capable receiver. Modifications made at > the forwarders can be understood by the receiver, and potentially reversed > to see the state of the message coming to the forwarder. > > To motivate this, let's look at example of the message as it traverses the > forwarder: > > *DKIM1 → DKIM2* > > Sent by originator: > > > DKIM-Signature: d=originator.com > > From: [email protected] > > MAIL FROM: <[email protected]> > > RCPT TO: <[email protected]> > > *DKIM1 → DKIM2 → DKIM2 * > > Sent by modifying forwarder: > > DKIM2-Signature: i=1; d=forwarder.com; [email protected]; rt= > [email protected]; > > Message-Instance: i=1; rh=From,DKIM-Signature; rb=c:.... > > DKIM-Signature: d=forwarder.com > > From: <[email protected]> > > MAIL FROM: <[email protected]> > > RCPT TO: <[email protected]> > > So far so good. You can see the Message-instance contains recipes to > reverse the changes made by forwarder such as rewriting the From and > DKIM-Signature header fields. But there are a couple of problems. First > this makes the forwarder vulnerable to replay that would be introduced to > the DKIM2 ecosystem. Presumably it is up to local-policy at the forwarder > to prevent replay and if they don't then they take responsibility for > replay abuse seen. After all, they are well identified by DKIM2. Second, > if there is bounce at receiver.com, there isn't a way to communicate the > return path at the forwarder back to the originator. If we want to keep > DKIM2 style bounce handling, perhaps we could invent a new tag e.g. "rp=" > to declare where to send the bounce. This would only be found at i=1 and > could also declare the DKIM1 → DKIM2 interop scenario. Alternatively it > might be inferred by the top most Return-path header perhaps. > > DKIM2-Signature: i=1; d=forwarder.com; [email protected]; rt= > [email protected]; [email protected] > > Message-Instance: i=1; rh=...From; DKIM-Signature; > > DKIM-Signature: d=forwarder.com > > From: <[email protected]> > > or > > *Return-Path: <[email protected] <[email protected]>>* > > DKIM2-Signature: i=1; d=forwarder.com; [email protected]; rt= > [email protected] > > Message-Instance: i=1; rh=...From; DKIM-Signature; > > DKIM-Signature: d=forwarder.com > > From: <[email protected]> > > Let's now consider the earlier problem, and the scenario DKIM2 → DKIM1. > The DKIM1-only receiver depends on the DKIM2-capable sender also supplying > DKIM1 signatures which we propose makes sense for compatibility. Then > there is the DKIM2 → DKIM1 → DKIM2. At the Receiver, the last > DKIM2-Signature rt= i.e. at i=1 will mismatch RCPT TO recipient address, > and look indistinguishable from replay. > > thanks, > > -Wei > >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
