Richard, The use-case William describes (a mailing list sitting in the middle which isn't DKIM2 aware) seems likely and legitimate in the intermediate case. Presumably the mailing list is already taking ownership of the messages because of DKIM and DMARC. A forwarder in the middle then receives a DKIM1 mailing list message (or message that just started out DKIM1 only) and needs to forward it along. In my mind, this is effectively a "new message" that the forwarder is sending, and the forwarder has to take ownership.
Richard, do you agree for the medium term that it's legitimate for the forwarder to start a new DKIM2 chain having taken ownership as the originator? If so, am I understanding your position correctly, to be that this is already clear from the current text and doesn't need to be specified further (since the mail would be DKIM2 authenticated and so the current spec would not suggest rejecting it)? Or are you saying in this situation the message is a lost cause, no further DKIM2 headers should be added and the message should just be passed along with only DKIM1 authentication for downstream receivers to decide whether to reject based on that? DKIM1 currently allows the forwarder to pass along the message without modification. ARC helps forwarders comparatively more because now they can pass the mail along and don't make problems worse because if the next hop wants to take a stricter policy they can look inside the headers and see it came into the forwarder unauthenticated and reject the message (I can attest that this was very helpful as I deployed no auth no entry in the past to handle forwarders without lowering the bar). So if DKIM2's stated policy is that the forwarder should reject messages missing DKIM2 and not forward them along, then I think that is an unnecessary regression which can be solved in better ways by the spec allowing the forwarder to describe the situation accurately so they do not worsen the situation and enable reputation laundering or amplification attacks. Some items that also aren't obvious to me from the spec: 1) What does "don't pass it along mean"/"start a new DKIM2 chain". I think it means don't pass along the existing DKIM2 headers. (If right, I think it's worth just stating that) If you are going to send the message along consider it a new message and start a new chain claiming ownership starting at yourself. There are different solutions to accomplish this: strip the previous DKIM2 headers, append "X-" to all the previous headers etc. 2) A clear and consistent way to describe I received this mail from xyz envelope MailFrom (identical to the DKIM domain). 3) I might be missing something basic but if the forwarder takes ownership and starts a new chain then do they also have to modify the fromHeader to align with their domain (This seems weird since they weren't modifying any text and the original DKIM1 still validates)? Or is there a way for them to say the chain starts with the previous message but got interrupted (similar to the "imaginary hop")? 4) I implicitly assumed that the spec would add some medium amount of value for a message that started off DKIM1 and at least allow securing the chain from that point forward (reducing DKIM replay potential by a small but non-zero amount). This allows a gradual transition as more and more of the ecosystem moves to DKIM2. But it seems like the spec's vision is more black and white maybe? Where you're either in the DKIM2 world or you're not, and there's no mixing between the two. If so, I do think that's worth spelling out. Personally, I'm concerned operationally if that will make the transition more challenge compared to supporting the partial case. Best, Emanuel On Wed, Aug 26, 2026 at 4:14 PM Richard Clayton <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <[email protected]>, Vittorio > <[email protected]> writes > > >The chain-of-custody model in draft-05 shares a property with any DKIM2 > >design built on the same foundation: it assumes the modifying parties on > >a path participate in the chain. Section 7 addresses the transparent > >case explicitly - an MTA that changes nothing "need not be made DKIM2 > >aware." That is correct and welcome. What is not addressed is the other > >case: a node that is not DKIM2-aware and does modify the message - a > >list rewriting a Subject and appending a footer, a gateway altering the > >body. This breaks the chain and it is not an edge case; during > >coexistence it is the common case, for as long as any non-participating > >node sits on ordinary delivery paths. > > I disagree -- the spec does cover this case very clearly. A DKIM2 system > that receives a message without a valid DKIM2 signature is required to > reject the message. > > Since such a system may wish, by local policy, not to reject then the > spec makes it clear that they should not pass the message to anyone > outside of their organisation, because that next system will also detect > the lack of valid system and will not only reject it but may ding your > reputation as well. > > >When this was raised earlier, the response was that such a message falls > >to local policy. I want to be precise about why that answer does not fit > >the problem. > > local policy is a way of saying that if you want to accept invalid DKIM2 > messages then go ahead, no-one can stop you > > > Local policy governs what a receiver does with a message - > >accept, reject, flag. It cannot govern whether two implementations > >interoperate across a path that includes a node neither of them > >controls. > > nothing could possibly do that if the intermediate node alters the body > or header fields of a message in a way that breaks the signature > > >A chain broken by a non-participating node produces, at the > >next hop, a verification failure whose cause cannot be determined from > >the message alone: it is indistinguishable from an attacker who altered > >the same content after signing. > > correct -- which is why the spec's position is that you should reject > the message -- the sending system can work out what has gone wrong, it's > not your problem > > the spec then (perhaps superfluously) cautions you not to assume anyone > else will think your local policy was wise -- so don't pass the message > on to strangers > > >Delegating that to local policy does not > >resolve the interoperability question; it declares that the > >specification will not address it. > > how could it -- criticising any authenticatiom system, not just DKIM2, > by saying "it has no way of dealing with systems that do not use it" is > a waste of our time > > >For a problem that is, at its root, > >about interoperability during a multi-year transition, that is the wrong > >layer to leave it at. > > what do you want the spec to say ... shame about the signature, pass on > the bad email and hope no bad people are involved ? > > >I raise this now because draft-05 has closed several open points but not > >this one > > this is not an open point ... the spec says what to do with mail that > does not authenticate. You may wish to do something else ... that's your > local policy. Have fun. > > - -- > richard @ highwayman . com "Nothing seems the same > Still you never see the change from day to day > And no-one notices the customs slip away" > > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 > > iQA/AwUBao9yzmHfC/FfW545EQLuzgCg+AZ++WIWzoZjI+GoKG8PNbxvgpIAn1VR > OkO/XFADvpdTzMYarF51K8cn > =mgck > -----END PGP SIGNATURE----- > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
