Emanuel,
To answer your question directly: we rewrite all headers including From
(outbound From is the list address, our domain, p=reject aligned), and we are a
re-originator using null recipe. Reputation tracking on our domain is not the
issue -- we hold list admins contractually to maintain opt-in membership, and
low complaint rates are a structural property of that model, not aspirational.
The concern is what happens when receivers write DKIM2-aware local policy.
Right now no one is writing DKIM2 policy because DKIM2 is not deployed. When it
is, a receiver could reasonably write: "messages carrying References and
In-Reply-To but no DKIM2 chain are suspicious -- consistent with chain
evasion." Without BCP text, that policy is defensible. With BCP text that says
"threading markers without a chain is the expected and legitimate output of a
re-originating intermediary," that policy becomes a spec violation.
The DMARC p=reject and mailing lists situation is the template. Before p=reject
was widely deployed, the same argument was made: mailing lists with good
reputation will be fine. That turned out not to hold once receivers started
writing p=reject policy with no normative exception for mailing lists. The BCP
I am proposing is the equivalent of that missing normative statement -- written
now, before policy hardens, rather than after delivery starts breaking.
There is also a structural reason for re-origination that goes beyond
preference. We send per-recipient body variants: tracking removal produces
different results for different members depending on what is in each copy.
There is no single message instance to chain from. The null recipe /
re-originator path is not a workaround -- it is the only architecturally
coherent option.
What I want the BCP to say: re-originating intermediaries with documented
characteristics (p=reject DMARC, functioning accountability mechanism, stable
domain, low complaint rates) are a recognized deployment pattern, and threading
markers without a chain are the expected output of that pattern. Receivers
SHOULD NOT treat the absence of a chain as evidence of evasion when those
characteristics are present.
William Weiner
Weiner Advanced Development LLC, maker of EMail Parrot (emparrot.com)
From: Emanuel Schorsch <[email protected]>
To: "William Weiner"<[email protected]>
Cc: "John Levine"<[email protected]>, "ietf-dkim"<[email protected]>,
"ms"<[email protected]>
Date: Sun, 12 Jul 2026 18:09:55 -0600
Subject: Re: [Ietf-dkim] Re: DKIM2 with message encryption
William,
Can you be more specific about what your concern is? Are you planning to leave
fromHeaders unwritten and hoping recievers won’t penalize you? Or you planning
to rewrite fromHeaders and use the null-recipe and are still worried about how
recievers will treat you? If it’s the second, I expect most recievers who don’t
know you will simply track reputation on your overall domain and not trust your
null-recipe assertion much. But assuming you have very low complaint rates as
you say then that shouldn’t be an issue.
All of that is to say I think it’s a bit unclear what else you want to be
included in a BCP.
Best,
Emanuel
On Thu, Jul 9, 2026 at 3:04 PM William Weiner <william.weiner=
mailto:[email protected] > wrote:
John's comment about Proofpoint-style gateways is directly relevant to a thread
I started in June ("Privacy-preserving intermediaries and re-origination") and
to GitHub Issue #2 on dkim2wg/spec.
EMail Parrot is in the null-recipe category John describes: we strip tracking
content and rewrite URLs for privacy reasons and do not provide recipes that
would expose the previous message state. The architectural difference from
Proofpoint is the direction of accountability: Proofpoint has commercial
contracts with the sending enterprise, which provides its accountability
anchor. We have service agreements with list admins, who in turn have opt-in
membership relationships with their subscribers -- low complaint rates are a
structural property of the model, not aspirational.
John's "squeaky clean, fully authenticated, very few user complaints" is
exactly the operating mode we are in. Issue #2 is about getting BCP language
that tells receivers to treat that mode as the signal it is rather than leaving
it to adverse local policy.
William Weiner
Weiner Advanced Development LLC, maker of EMail Parrot ( http://emparrot.com )
From: John Levine < mailto:[email protected] >
To: < mailto:[email protected] >
Cc: < mailto:[email protected] >
Date: Thu, 09 Jul 2026 11:59:04 -0600
Subject: [Ietf-dkim] Re: DKIM2 with message encryption
It appears that Metin Savignano < mailto:[email protected] > said:
>Thank you for your replies and suggestions. Let me reply one by one.
tl;dr I think we understand what you want to do, and DKIM2 can't do it.
>> Surely you'd just wrap the entire DKIM2-signed email with encryption? If
>> not, then you're either creating a brand new email and your
>gateway is implicitly trusted, so NULL recipe or just an
>Authentication-Results header and no DKIM2 at all.
>
>Not sure if I understand what you mean by „entire mail“. When encrypting, most
>headers and the message body gets encrypted, and
>that block replaces the message body while most headers are left intact (like
>From and To). There are slight variations of that
>approach, but most of the time, that’s how it works.
That is indeed the traditional approach but it's pretty lame since it exposes
all the metadata in the headers. S/MIME lets you put the entire meessage in a
message/rfc822 MIME part, encrypt that, and send it along with dummy headers,
so the real message gets unwrapped by the recipient. See RFC 8551 sec 3.1.
You might as well do that, see below.
>And yes, if the backend mailserver is configured to always trust the gateway,
>we have no problem. However, with DKIM2, as I understand
>it, the gateway can achieve trust through its DKIM signature, which is an
>advantage because it would not require a specific
>configuration of the backend mailserver.
>
>Now my questions is, with a null recipe, the receiving server can no longer
>verify the original content (and there is no way around
>this, because everything else would render encryption useless), so how is this
>situation conceptually coped with?
You can't. The whole point of DKIM2 is to let you look back through all of the
message modifications.
We have a somewhat similar situation with Proofpoint-style security gateways
which rewrite URLs and remove message parts. They do not want the recipient to
be able to see the previous version of the message other than via what the
rewritten URLs provide. They're why we have null recipes.
>The only way out of this dilemma would be to have the receiving email client
>check the DKIM of the original message after it has
>decrypted the message. However, DKIM is supposed to be implemented by the
>server, right?
Yup, and that's where useful spam filtering happens, too, which is a problem if
you don't trust your
mail operator as you often don't. So as I said, unless you have an existing
relationship with the
recipient server, your best hope is to send mail that looks squeaky clean to
the server, fully
authenticated and provoking very few user complaints.
Since you are not the originating system, you can't apply a DKIM signature that
aligns with the original From: header so you can't get DMARC alignment that
way.
But you can put your own From: on a wrapped message with your own domain and
add
a signature that aligns with that.
While the DKIM2 angle is new, none of the other issues are and it would be a
good idea to see what other people have done. I'd suggest talking to Daniel
Kahn
Gillmor < mailto:[email protected] > who's active in the IETF and has done
more
thinking about this than anyone else I know.
R's,
John
_______________________________________________
Ietf-dkim mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
_______________________________________________
Ietf-dkim mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
