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]
