This thread feels like it's conflating a number of things, and that's causing you to think there's a problem when none exists.
A message with References/In-Reply-To can very legitimately have a DKIM2 chain with a single signature. That happens when a person replies to an email, like I'm doing now. It would be quite irrational to have a local policy stating that messages with these header fields need to have more than one DKIM2 signature to be considered legitimate. I don't think the BCP needs to call this out specifically. Null recipes are only relevant if you want to preserve the DKIM2 chain that was sent to you, but do not want to disclose the original message content to the next recipient. It also sounds like you don't want to disclose the original author, which is possibly included in the DKIM2 chain. A reasonable approach to this type of anonymizing is to delete all previous signatures and add your own signature as the first hop in the chain. From the perspective of a downstream receiving system, this would be indistinguishable from your system independently generating the email. I assume you are doing something similar for DKIM already for much the same reason, but I know nothing about your service. It is entirely reasonable for sites to have a local policy that makes the presence of a valid DKIM2 chain mandatory for message acceptance. It might be unwise, depending on how much legitimate but non-DKIM2 mail that site receives. As noted above, I don't think that such a policy impacts your service since you have a workable path to forming a valid DKIM2 chain. On Mon, Jul 13, 2026, 10:00 a.m. William Weiner <william.weiner= [email protected]> wrote: > 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= > [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 (emparrot.com) > > > > > From: John Levine <[email protected]> > To: <[email protected]> > Cc: <[email protected]> > Date: Thu, 09 Jul 2026 11:59:04 -0600 > Subject: [Ietf-dkim] Re: DKIM2 with message encryption > > It appears that Metin Savignano <[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 <[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 -- [email protected] > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
