I wasn’t around at the time so please correct me if I’m off base here but to me it seems like blocking mailing list mail for p=reject domains without fromHeader rewriting is an expected consequence of the spec. I know people disagree whether that’s a desirable behavior. But it doesn’t seem like an “irrational” application of the spec, to do otherwise would have been a widespread exemption for local policy to override for “trusted” mailing lists which wasn’t documented in the spec or bcp.
Personally, I don’t see any harm in writing down somewhere that mail which takes ownership shouldn’t be penalized just for trace headers / clues that it might have originated somewhere originally. But I’m also still not convinced that it’s necessary and not the ordinary interpretation that most recievers would arrive at from dkim2. Best, Emanuel On Mon, Jul 13, 2026 at 12:26 PM William Weiner < [email protected]> wrote: > > For context: EMail Parrot is a privacy-protecting email distribution list. > Members opt in; the list admin controls membership and is contractually > bound to maintain compliant list hygiene. Before re-delivering each message > to members, we strip tracking pixels, URL trackers, and identifying headers > to protect recipient privacy. We re-originate - signing outbound messages > at i=1 under our own domain - rather than forwarding, because providing a > chain would expose the original sender's identity and infrastructure to > recipients, which is precisely what the service exists to prevent. > > You are correct on the technical path: signing at i=1 as a fresh Sender > ADMD with no prior chain is exactly what we do and intend to continue doing. > > The concern is not whether this constitutes a valid DKIM2 chain. It does. > The concern is whether the BCP will give receivers normative guidance to > treat single-hop re-originator signatures on equal footing with any other > Sender ADMD, or whether the absence of a prior chain becomes a negative > signal under local policy. > > You note it would be "quite irrational" for local policy to penalize this > pattern. The DMARC p=reject and mailing list situation is worth remembering > here. When Yahoo and AOL published p=reject in 2014, receivers followed the > policy and legitimate mailing list traffic broke at scale - including on > IETF lists. Treating mailing list forwarded mail as non-DMARC-compliant was > also arguably irrational, but it happened because there was no normative > statement telling receivers to treat mailing lists as an expected > exception. The resulting workarounds (From munging) are still in use and > widely considered hacks. The BCP text I am proposing is that normative > statement for re-originators, written before local DKIM2 policy hardens > rather than after delivery breaks. > > The ask is one sentence in Section 6: a valid single-hop DKIM2 signature > from a re-originating service with documented characteristics (p=reject, > functioning abuse contact, stable domain reputation) SHOULD be evaluated on > the same basis as any other Sender ADMD originator, without prejudice for > the absence of a prior chain. > > William Weiner > Weiner Advanced Development LLC, maker of EMail Parrot (emparrot.com) > > > > From: Allen Robinson <[email protected]> > To: "William Weiner"<[email protected]> > Cc: "Emanuel Schorsch"<[email protected]>, "John > Levine"<[email protected]>, "ietf-dkim"<[email protected]>, "ms"< > [email protected]> > Date: Mon, 13 Jul 2026 08:49:28 -0600 > Subject: [Ietf-dkim] Re: DKIM2 with message encryption > > > 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: > > > > _______________________________________________ > > Ietf-dkim mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > 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]
