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]
