For the incoming case, DKIM2 handles this very well. r= recipes disclose the content of things from the EARLIER hops; and you can strip off any later hop information in any returned bounces.
Now your second case (redact sender identiy) - yes indeed, you are the originator of such a message, you create an i=1 message. Clearly, you don't want to provide any earlier hops regardless of redaction or not, because that would disclose domain identity and other details of the original sender. In this case, you are the originator, you can provide a nonce field which is a lookup into your own database to allow you to reconstruct who the "real" sender (at least as far as you know) of the message is - without disclosing that to anyone else. You'll also be stripping received headers and all sorts of other things, possibly even rewriting the message-id header since that might disclose system information. So for sure you're minting a brand new message. Bron. On Fri, Jun 12, 2026, at 18:25, William Weiner wrote: > I operate a relay service whose purpose is recipient privacy: it > removes tracking content (pixels, per-recipient link tokens, > fingerprints) and redacts sender identity (group members communicate > without exposing their addresses to each other or to external > parties). Alias/forwarding privacy services face similar issues. I > want to flag how this class of intermediary interacts with the > Reviser model, and suggest a small addition to the (currently TBA) > considerations text. > > This relates tangentially to the recent multiple-domain-signatures > discussion about where chains begin and which boundaries they map to: > a privacy-preserving intermediary is an authorship boundary, and the > chain beginning there is the correct outcome, not a degraded one. > > Reviser status appears structurally unavailable to a > privacy-preserving intermediary, at any recipe setting: > > 1. With recipes (4.1/4.2), the r= tag allows recreation of the > previous message instance - i.e., it discloses exactly the > content the service exists to remove (original From, tracking > elements, pre-redaction body). > > 2. With null recipes (permitted by 4.1/4.2), the chain itself still > discloses identity: section 6.1 requires unbroken Message-Instance > numbering, so prior DKIM2-Signature header fields must be > retained, and section 7 requires mf=, rt= and d= in each. The > originating hop's envelope addresses and provider domain therefore > travel to every recipient regardless of content reversibility. > > 3. Separately, such services commonly emit per-recipient body > variants (one inbound message becomes N distinct outbound > messages). There is no single "instance 2" for a Message-Instance > header to describe. Note this also applies to conventional list > personalization such as per-recipient unsubscribe footers. > > The consequence is that privacy-preserving intermediaries will > terminate the inbound message and re-originate (m=1, own domain, own > signature). First-hop authentication is clean; the chain simply > begins at the relay. The spec already contemplates trusted > information-destroying intermediaries (the null-recipe text in > 4.1/4.2, "contractually arranged service"); intentional > re-origination for privacy is the adjacent case. > > The ask: when the considerations sections are written, acknowledge > intentional re-origination by privacy-preserving intermediaries as a > legitimate deployment pattern, so that downstream deployment or > reputation guidance does not treat an absent chain as evasion. Happy > to propose text. > > William Weiner > Weiner Advanced Development LLC, maker of EMail Parrot (emparrot.com) > > > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
