Todd, I posted to ietf-dkim last week about how privacy-preserving relay services interact with the Reviser model (thread: "Privacy-preserving intermediaries and re-origination"). Bron and Emanuel both confirmed the re-originator framing: such services are Sender ADMDs in DKIM2 terms, taking full ownership of outbound messages (m=1).
We are tracking DKIM2 development with the intent to be fully compliant as the spec and deployment guidance mature. With that as our posture, we want to make sure the BCP defines the re-originator category clearly enough that compliance is well-defined for services like ours -- and that receivers have enough guidance to handle this category without defaulting to adverse treatment. Section 5.8 of draft-herr-dkim2-bcp-01 is a stub. Section 6.3 leaves chain-less message handling to local policy without distinguishing intentional re-origination from chain evasion. I want to offer text for both, and to raise one additional mechanism worth considering. --- Background: how receivers recognize re-origination --- A receiver cannot identify a specific relay service from message content alone, but it can recognize the category. The most specific technical tell is threading markers without a chain: a message carrying References and In-Reply-To headers -- indicating a reply in a thread -- but no DKIM2 chain history. Original compositions carry no threading headers; a Forwarder or Reviser would carry both. Threading markers present with no chain is the fingerprint of re-origination. This is not an anomaly. It is the expected output of a relay that terminates and re-originates messages by design. The BCP should say so. --- Proposed text for Section 5.8 --- Rename or expand the section to: "Privacy-Preserving Re-Originating Relays" Some privacy-preserving intermediaries -- relay services, alias services, and similar -- intentionally terminate the inbound message before re-delivery rather than forwarding it. This is deliberate re-origination: carrying a chain of custody would disclose the original sender's domain, provider identity, and message envelope to recipients, which is precisely the information these services exist to protect. Providing a chain in this case defeats the service's purpose regardless of recipe setting. Such services act as Sender ADMDs in DKIM2 terms. They sign outbound messages from their own domain (m=1) and bear full accountability for those messages. The absence of a prior chain is a design property of this deployment pattern, not an anomaly. This applies equally to services that emit per-recipient body variants from a single inbound message, for which there is no single message instance to chain from. A defining characteristic of legitimate privacy-preserving re-originators is that all message modifications serve the recipient, not the relay. Tracking content is removed to protect the recipient. Any additions -- such as documentation of removed content or relay identification -- inform the recipient rather than serving the relay's interests. This distinguishes legitimate services from malicious re-originators, which inject content (phishing links, malicious payloads, surveillance beacons) that serves the attacker at the recipient's expense. Privacy-preserving re-originators SHOULD: o Sign all outbound messages with a DKIM2 signature from their own domain, with strict DMARC alignment (p=reject or p=quarantine). o Include an opaque nonce field (for example, a keyed hash of the inbound message identifier) as a lookup into their own records, so that they can respond to legitimate accountability queries without disclosing sender identity in the message itself. A nonce that maps to a record past the service's retention window is a transparency statement: the underlying message is gone by design and the service can say so. o Strip Received headers, rewrite Message-ID, and rewrite References and In-Reply-To to their own domain namespace, to prevent originating-system identifiers from propagating to recipients across the re-origination boundary. o Maintain a functioning abuse contact, participate in major provider feedback loops, and honor removal requests promptly. o Publish a machine-readable relay policy declaration on their sending domain (see proposed mechanism below). --- Proposed addition to Section 6.3 --- Add after the first paragraph: Receiver ADMDs SHOULD NOT treat the absence of a DKIM2 chain as evidence of evasion or abuse when the sending domain carries a valid DKIM2 originator signature. Privacy-preserving relay services legitimately originate fresh messages (m=1) without prior chain history as a deliberate privacy property. A message carrying threading markers (References, In-Reply-To) without a chain is the expected output of a re-originator, not an indicator of evasion. Receivers SHOULD treat messages from declared privacy relays (see proposed mechanism below) equivalently to messages from any other Sender ADMD. Receivers SHOULD NOT apply adverse disposition solely because no prior chain is present. A privacy-preserving relay operates under a service agreement with the subscribers who direct their mail through it. Adverse treatment of the relay's output does not identify bad mail -- it penalizes the recipient's deliberate choice about how to receive their own email. This is the same class of problem that DMARC p=reject created for mailing lists: a spec-silent gap in local policy that translated into delivery harm for operators and users with a legitimate reason to look different from the modal case. --- Proposed new mechanism: Declared Privacy Relay Policy --- The BCP should define a mechanism by which a re-originating relay can publish its operational status in a domain-authoritative, machine-readable form -- analogous to the DMARC TXT record. A DNS TXT record or a resource at /.well-known/relay-policy on the sending domain would serve this purpose. A declared privacy relay would publish at minimum: o Service type declaration (this domain operates as a privacy-preserving relay) o Abuse contact o Nonce lookup endpoint for authorized accountability queries o Link to human-readable operational policy Criteria for declared relay status that receivers can evaluate: o Published relay policy record on the sending domain o Strict DMARC (p=reject or p=quarantine) on the sending domain o Functioning abuse contact with demonstrated responsiveness o Stable sending domain with established reputation o Low bounce and complaint rates consistent with an opted-in subscriber base o Nonce-based accountability mechanism A malicious operator can publish a relay policy record, but doing so permanently associates the claim with their sending domain and increases their accountability for it. The combination of a published declaration, strict DMARC, low complaint rates, and a functioning nonce-based accountability mechanism is not practically sustainable by a bad actor at scale. This is the differentiator the BCP currently lacks: a way to define what legitimate re-origination looks like, not just note that it exists. The mechanism sketch above is offered as a starting point for discussion rather than a finished proposal. Whether it belongs in this BCP or a separate document is a question for the working group. The intent is to provide differentiation between valid and malicious re-originating of emails. All these proposals are offered as starting points for dialog and I'm happy to participate as desired. 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]
