Richard, This also addresses your reply in the BCP thread.
On the service model: EMail Parrot is a list relay, not a pass-through forwarder (just like mailman). Members opt in; the list admin controls membership. The complaint and reputation concerns you raise are real for generic forwarding services. They are handled by the list model -- low complaint and bounce rates are a property of opted-in membership, not an afterthought. On "how would they know unless you told them": a reply flowing through EMail Parrot carries References and In-Reply-To headers but no DKIM2 chain. Original compositions carry no threading headers; a Forwarder or Reviser would carry both. Threading markers present without chain is a detectable fingerprint of re-origination. A receiver writing local DKIM2 policy in a few years could use that pattern as a negative signal. That is the specific gap. On the need for BCP guidance at all: this thread is itself going through Mailman, which has the same structural property. Mailman can implement the Reviser model under DKIM2, and for a public archived list like this one that is fine -- the chain would show that the sender is a member of list.ietf.org, which is already public. But a private Mailman list -- a family group, a closed business list, a support community -- faces the same issue: the chain leaks membership information to every recipient through the custody chain nodes. And Mailman installations that have not yet implemented DKIM2 will produce chain-less mail in exactly the same position as EMP. The need to say 'this is expected and SHOULD NOT be treated as evasion' is not abstract -- it describes software that has been running for twenty-five years and is running this list right now. The concern extends well beyond services like EMail Parrot. On the declared relay mechanism: you are right that no self-declaration overrides reputation systems, and I did not mean to suggest otherwise. The ask is narrower than my email made it sound. The core request is a single normative statement in Section 6.3: threading markers without chain SHOULD NOT be treated as evasion. Your description of local policy as "an IETF joke" is actually the problem I am describing -- undefined local policy is what allowed p=reject to break mailing lists, not a normative requirement in the spec itself. We will file proposed text on GitHub. William Weiner Weiner Advanced Development LLC, maker of EMail Parrot (emparrot.com) From: Richard Clayton <[email protected]> To: <[email protected]> Date: Wed, 17 Jun 2026 19:05:11 -0600 Subject: [Ietf-dkim] Re: Privacy-preserving intermediaries and re-origination (Reviser model, sections 2.3, 4, 6, 7) > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <63758d82-0fe7-4cbc-a00b-3b18829ec68a@Spark>, william.weiner= > [email protected] writes > > >With the protocol framing settled, I want to flag a gap in > >draft-herr-dkim2-bcp- > >01. Section 5.8 is currently a stub whose heading gestures at > >privacy-preserving > >behavior. > > what has been discussed is the notion that a system wishes to forward a > message to a new destination without the sender learning what that > destination might be. The recipient will get the message in the normal > way but if they decide they don't want it then, since the "bounce" (the > DSN) flows back along the outgoing path the forwarder can ensure that no > evidence remains of where they sent the message to > > in fact, as discussed at the interim meeting this evening, in order to > make DSN handling tractable when the outgoing path visits the same > machine more than once, stripping what happened during forward must be > removed ... also as a loose end there will be a new flag to ensure that > a system can ask that "feedback" is not sent direct from destination to > the origin of the email > > >Section 6.3 leaves receiver handling of chain-less messages to local > >policy, with no guidance distinguishing intentional re-origination from > >chain > >evasion. As DKIM2 deployment matures and major receivers write their local > >policies, that gap is where a trust gradient against legitimate > >re-originators > >could quietly emerge. > > "local policy" is kind of an IETF joke... it generally means there is no > policy or anything to rely upon. The system does what it feels like. > > >I will be sending proposed text for both sections directly to Todd Herr and > >will > >cc this list for the record. > > we work on the list, but Todd may well appreciate it being drawn to his > attention (which you can also do, shortly, within Github) > > - -- > 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/AwUBajNER2HfC/FfW545EQLUlgCg+SaF6sd0FPdKIMBgIbKDZF1JaUoAn1FJ > DakcvcL2GwIhmQRhcLEpugjl > =uT3h > -----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]
