The proposed text is in GitHub Issue #2 at https://github.com/dkim2wg/spec/issues/2, which also contains the proposed Section 5.x definition of re-originating services. The relevant Section 6.1 addition is reproduced below.
The email summary you are responding to was imprecise on two of your points. "p=reject" was an inline shorthand and should not be in the normative text - "authenticated sending domain" is the right framing. "Functioning abuse contact" is also vague; "published abuse contact" is more precise and avoids the definitional problem. Both are fair corrections. On local policy: the goal is not to override irrational policy - you are right that no BCP does that. The goal is to give rational implementers writing DKIM2 receiver policy for the first time a normative anchor, before deployment patterns harden. The specific concern is messages that carry standard list headers (List-Id, List-Unsubscribe, etc.) alongside a single-hop originator signature. Without BCP guidance, a policy author might reasonably treat "list headers + no chain" as a suspicious pattern worth penalizing. The proposed SHOULD prevent that interpretation from taking root. A re-originating service does not remove accountability - it substitutes its own domain and reputation for the original sender's. If it enables spam or phishing, the complaint signal lands on the relay's domain directly. The accountability mechanism is intact; it operates at the relay layer rather than the author layer." Proposed Section 6.1 addition: Receiver ADMDs SHOULD NOT treat a message bearing a single valid DKIM2 originator signature as suspicious solely because no prior chain is present and the message carries threading markers (References, In-Reply-To). Threading markers without a prior chain is the expected and legitimate output of a re-originating intermediary (see Section 5.x). A valid single-hop DKIM2 signature from a re-originating service should be evaluated on the same basis as any other Sender ADMD originator signature. William Weiner Weiner Advanced Development LLC, maker of EMail Parrot (emparrot.com) From: Richard Clayton <[email protected]> To: <[email protected]> Date: Thu, 16 Jul 2026 00:21:26 -0600 Subject: [Ietf-dkim] Re: DKIM2 with message encryption > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <19f5c160bc3.1b25e9471433010.3436756724027830514@wadevelopmen > t.co>, William Weiner <[email protected]> > writes > > >The concern is not whether this constitutes a valid DKIM2 chain. It does. > >The > >concern is whether the BCP will give receivers normative guidance to treat > >single-hop re-originator signatures on equal footing with any other Sender > >ADMD, > >or whether the absence of a prior chain becomes a negative signal under > >local > >policy. > > the vast majority of email goes from A to B and never goes anywhere else > > why would a BCP need to say anything about that ? > > >You note it would be "quite irrational" for local policy to penalize this > >pattern. > > many local policies are irrational -- but they are local and no BCP will > make any difference to that one way or another > > >The BCP > >text I am proposing is that normative statement for re-originators, written > >before local DKIM2 policy hardens rather than after delivery breaks. > > I'm sorry, I missed the text that you are proposing. Please could you > repeat what it was... if it was along the lines of "local policy MUST > be something or other" that is clearly nonsense because that would make > what is being described something other than "local policy" > > >The ask is one sentence in Section 6: a valid single-hop DKIM2 signature > >from a > >re-originating service with documented characteristics (p=reject, > >functioning > >abuse contact, stable domain reputation) SHOULD be evaluated on the same > >basis > >as any other Sender ADMD originator, without prejudice for the absence of a > >prior chain. > > ah right you are proposing something ... but you seem to have missed out > the definition of what a "re-originating service" might be, you are > tying it to DMARC (which seems problematic), you have not explained what > "functioning" means in terms of an abuse contact (whatever that is) > [[and note that RIPE have been tying themselves in knots for years for > this issue in respect of IP address allocation]] ... and finally I am > unsure what a Sender ADMD originator might be. > > - -- > 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/AwUBalh4ZmHfC/FfW545EQKtowCglcXG6HukicWO+3wMbUbvIFrjnbEAn3i3 > 1NHMO8zRwi4O1f42UpVyxYtJ > =8SO7 > -----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]
