BCP gap: re-originating intermediaries are a distinct category not addressed in Section 5 or Section 6

[bweiner]

Background

I operate EMail Parrot (emparrot.com), a privacy-preserving list relay. This
issue follows a thread on ietf-dkim (June 2026, "Privacy-preserving
intermediaries and re-origination") in which Bron Gondwana and Emanuel
confirmed that services like EMail Parrot are re-originators -- Sender ADMDs
in DKIM2 terms -- rather than Forwarders or Revisers. This issue proposes BCP
text to address that category, with a note on a related protocol consideration.

The gap

The BCP defines Sender ADMD, Forwarder, and Reviser behavior but does not
address a distinct class of intermediary: the re-originating service. These
services receive a message, terminate it, and originate a new message from
their own domain. They are valid single-hop Sender ADMDs. Section 5.8 (Bron's
DSN bounce path idea) addresses a related but different privacy mechanism.
Re-origination itself has no BCP coverage.

Structural context

The spec correctly addresses the needs of large corporate email operators
through mechanisms like delegated DNS selectors and multi-hop chain
documentation. Those mechanisms assume the intermediary either controls the
sending domain or has commercial relationships enabling delegated credentials.

Enterprise email security gateways -- including Proofpoint Targeted Attack
Protection, Mimecast URL Protection, and Microsoft Defender for Office 365
Safe Links -- can sign outbound mail using the client's domain (d=client.com)
via delegated selectors, keeping the vendor's infrastructure identity out of
the custody chain. This protects both the client's security posture and the
vendor's proprietary configuration from external inspection.

No equivalent mechanism exists for privacy-preserving re-originators. This
gap represents an omission based on early deployment profiles rather than an
intentional architectural exclusion -- the BCP was developed from enterprise
and large-ISP deployment scenarios where this pattern did not arise. But the
structural effect is that re-originating privacy services are
indistinguishable from malicious actors in the protocol as currently
specified, despite serving clearly beneficial purposes. Closing this gap is
the purpose of this issue.

Affected services

Two related problems fall under this gap.

Problem 1 -- Re-originating intermediaries produce valid single-hop DKIM2
mail with no prior chain. When a reply flows through a re-originating relay,
the outbound message carries References and In-Reply-To headers but no DKIM2
chain. Original compositions carry no threading headers; Forwarder or Reviser
messages would carry both. Threading markers present without chain is the
expected and legitimate fingerprint of re-origination. A receiver writing
local Section 6.1 policy could treat this pattern as a negative signal. The
BCP says nothing about it.

Services in this category include: privacy relays (EMail Parrot, Proton,
SimpleLogin), alias services (Apple Hide My Email, DuckDuckGo Email
Protection, Firefox Relay), mailing list managers performing From-munging, and
university and alumni forwarding services that reconstruct messages at the
relay layer.

Problem 2 -- Reviser chain exposure affects intermediaries that CAN
participate in the chain but face real costs for doing so. Mailman is the
immediate example: acting as a Reviser includes the list's domain in the
custody chain of every message handled. For a public archived list this is
fine. For a private Mailman list -- a family group, a closed business list, a
support community -- the chain leaks list membership to every recipient. This
is a privacy regression relative to current behavior.

As noted above, enterprise security gateways can address the analogous
problem through delegated selectors. Private mailing lists have no equivalent
mechanism.

The common root: the BCP does not address why a legitimate intermediary might
limit chain participation to protect sensitive information, or what receivers
should do when they encounter that choice.

Proposed new section 5.x -- Re-Originating Intermediaries

Place after Section 5.8.

---

Some intermediaries -- privacy relay services, alias services, and similar --
intentionally terminate the inbound message and originate a fresh outbound
message 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 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 re-originating intermediaries is that
all message modifications serve the recipient or sender -- tracking content
removed, headers redacted, content normalized -- rather than benefiting the
intermediary at the user's expense. Malicious re-originators inject content
(phishing links, malicious payloads, surveillance beacons) that serves the
attacker. The direction of transformation distinguishes the two categories.

This distinction is observable at the message level, but the more durable
differentiator is operational: a legitimate re-originator sustains a stable
sending domain, p=reject DMARC alignment, low complaint and bounce rates, and
a functioning accountability mechanism over time. A malicious actor using the
re-originator pattern as cover cannot maintain that combination at scale.

Re-originating intermediaries SHOULD:

• Sign all outbound messages with a DKIM2 signature from their own domain,
  with a published domain policy ensuring alignment between the signing domain
  and the visible sender domain.

• Include an opaque, deterministic nonce header (for example, a keyed hash of
  the inbound message identifier) to support legitimate accountability queries
  and active abuse mitigation without disclosing sender identity in the message
  itself. When a receiver ADMD reports abuse against a specific nonce, the
  re-originator can execute targeted mitigation -- rate-limiting or suspending
  the inbound source -- without revealing that identity to the receiver. A
  nonce that maps to a record past the service's retention window indicates the
  underlying message has been deleted per the service's retention policy.

• 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 across the re-origination boundary. This
  rewriting creates a one-hop threading discontinuity for the original sender
  of a message: their outbound Message-ID does not match the re-originated ID
  recorded in subsequent replies. All other recipients of the thread see
  consistent threading throughout. This is an accepted tradeoff for
  cryptographic anonymity at the re-origination boundary.

• Include a signed transparency header documenting the categories of
  normalization performed (for example: tracking-pixels-removed,
  url-params-stripped, headers-redacted), so receivers can distinguish
  intentional privacy processing from malicious content modification. Unlike
  a Reviser recipe, this is an originator declaration -- it documents what
  the re-originator did before signing, not what changed relative to a prior
  signed state.

• Maintain a published abuse contact and participate in relevant feedback loops.

---

Proposed addition to Section 6.1

Add after the first paragraph:

---

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.

---

Related protocol consideration -- f= flag

The f= flags field in the DKIM2-Signature header provides a natural
per-message complement to the BCP guidance above. Registering a standardized
flag value (such as f=reorigin) for re-originating intermediaries would allow
receivers to identify this pattern directly from the authenticated signature,
without requiring out-of-band DNS lookups. A flag from a stable domain with
published policy, published domain policy, and a published abuse contact
carries meaningful signal; the same flag from a throwaway domain without those
properties does not -- making the combination resistant to abuse by bad actors
claiming the flag without the supporting infrastructure. This may warrant a
separate issue against the spec.

Related issue -- private mailing lists and Reviser chain exposure

The BCP should address whether there are conditions under which a Reviser
intermediary may legitimately limit chain participation to protect sensitive
information -- specifically list membership for private mailing lists. Guidance
that chain participation SHOULD NOT be required when doing so would expose
information the intermediary is contractually or operationally required to
protect would address Problem 2 above without creating a general exception.
This may warrant a separate issue.

---

William Weiner
Weiner Advanced Development LLC, maker of EMail Parrot (emparrot.com)
ietf-dkim thread: "Privacy-preserving intermediaries and re-origination", June 2026

[bweiner]

A recent real-world incident reinforces the receiver-side premise behind this
issue, from the opposite direction, and I think it is worth recording here.

I received a transactional auto-acknowledgement from a large vendor's marketing
platform. An attacker had submitted the vendor's "contact us" web form with a
payment-fraud lure injected into a free-text field that the platform echoes
verbatim into its confirmation message. The platform DKIM-signed that content
under the vendor's own domain and delivered it to an address the attacker chose:
a mailbox in a compromised Microsoft 365 tenant, which auto-forwarded it onward.
By the time it reached me it carried a valid vendor DKIM signature, an ARC seal
from the forwarding tenant, and DMARC pass under the vendor's quarantine policy.
Every mechanical signal was green; the payload was fraud.

This is not itself a re-origination case. It is a forwarding/replay laundering
chain, and the DKIM2 chain mechanism is designed to make that path legible. I
raise it because it demonstrates the premise underneath both changes proposed in
this issue: a fully chained, mechanically valid custody path can carry malicious
injected content, while a chainless single-hop re-originator can be entirely
benign. Chain presence and signature validity do not separate the two. The
direction of transformation and the originator's sustained operational behavior
do.

This is the same class of mistake the community already made once, with
p=reject. The protocol was silent on indirect mail flows, receiver handling was
left to local policy, and mailing lists broke; ARC and the DMARC
interoperability guidance were the retrofit. Leaving receiver handling of
chainless re-originated mail to undefined local policy sets up the analogous
failure. Heading that off is what the BCP is for; it is not a protocol-spec
change.

The practical risk is symmetric. If receiver guidance lets operators weight
custody-chain shape as a trust proxy, attackers will manufacture clean chains, as
happened here, and legitimate re-originators will be penalized for lacking one.
Both errors share a root cause. Anchoring receiver evaluation on operational
reputation -- stable sending domain, strict DMARC alignment, low complaint and
bounce rates, and a functioning accountability mechanism -- addresses both, and
is the guidance I believe the proposed Section 5.x and the receiver-side
addition should make explicit rather than leave to local policy.

William Weiner
Weiner Advanced Development LLC (EMail Parrot)

[bweiner]

The -03 revision published June 24 adds two flags directly relevant to this issue: "exploded" and "feedhere". Both confirm the WG is actively developing mechanisms to address privacy and fan-out concerns -- but the additions also sharpen the gap this issue describes.

exploded (Section 8.10)

The "exploded" flag addresses the DKIM-replay-vs-fan-out distinction: a mailing list that sends multiple copies of the same message body can set this flag so receivers know the fan-out is expected rather than a replay attack. For a Reviser-based list (Mailman in chain mode), this works cleanly -- the flag appears in the list's chain signature, backed by the chain that proves who the list is.

For re-originators, the flag is available but underdefined. A re-originating relay signing at m=1 with no prior chain can set f=exploded, but there is no BCP guidance on how receivers should evaluate it. A flag from a stable domain with p=reject and a functioning accountability mechanism is different from the same flag on a throwaway domain, but the spec provides no basis for receivers to distinguish the two when there is no chain. The gap in Section 6.1 guidance this issue identifies applies directly here.

feedhere (Section 8.10)

The "feedhere" flag lets a Forwarder route feedback signals through itself so downstream destinations are not revealed to the original feedback requestor. The spec describes it as a mechanism for "privacy-conscious Forwarders." This addresses a real privacy concern, but specifically for chain participants: the forwarder intercepts the feedback path at its chain hop.

Re-originators do not appear in the chain at all. There is no hop to intercept. The nonce-based accountability mechanism proposed in this issue is the re-originator's equivalent -- feedback routed to an abuse contact, resolved internally against a nonce-to-source record, without revealing identity to the reporter. That gap remains unaddressed in -03.

Summary

Both additions confirm the WG is working on mechanisms that serve privacy interests for chain participants. nd= (also new in -03) hides infrastructure for chain participants. feedhere routes feedback privately for chain participants. exploded signals fan-out intent for chain participants. Re-originators who cannot and should not participate in the chain by design have no parallel mechanism for any of these properties. That is the structural gap this issue proposes to address in the BCP.