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]
