I wanted to introduce a couple of comments about the JSON proposal. First, I think that the BASE64 encoded JSON will introduce friction when manually inspecting DKIM2 hop-to-hop information particularly around domain alignment. While some may claim that tools will improve debug, I think we have all found it useful to sometimes read through headers to solve some delivery problems. The proposed BASE64 encoding will cause operators to lose a step when doing manual inspection. Second, that said, I agree that JSON can help with represents DKIM2 "algebra" "recipes" as it provides structure to represent potentially multiple header and body mutations. The body diff mutations are likely difficult for anyone but a machine to read anyways. I think the main benefit of human readability is with comparing the DKIM2-Signature values of "rt=", "mf=", "d=" tags and comparing across hops and with other header fields. So I'd like consideration of the DKIM1 tag-value for the DKIM2-Signature header field and BASE64-encoded JSON for Message-Instance. Agreed, specifying the RT address list ABNF will require more work (and let me know how I can contribute here). -Wei
On Thu, Jan 22, 2026 at 10:06 AM Tobias Herkula <tobias.herkula= [email protected]> wrote: > Hi all, > > having reviewed the current DKIM2 drafts, I would like to propose a > simplification of the wire > representation. > > Relative to DKIM1, DKIM2 elevates “hop semantics” to first-class, signed > assertions (e.g., mf/rt, > chain intent, and potentially large recipient sets). My concern is that > encoding these > semantics primarily as an expanding set of tag=value parameters will (a) > increase syntactic > surface area, (b) incentivize ad-hoc list grammars, and (c) ultimately > produce fragile parsers > and interoperability friction. > > Proposal: represent the majority of DKIM2 hop metadata as a single > base64-encoded JSON > object, while constraining the DKIM2 header tag list to the minimal set > required for signature > mechanics. > > I am explicitly suggesting JSON (rather than a binary encoding), because > even when base64- > encoded it remains operationally transparent: it is trivially decodable > and therefore > inspectable by operators with standard tooling. In practice, that level of > human readability is > close to a requirement for deployment, troubleshooting, and incident > response. > > Benefits: > > * Recipient-scale: large and/or structured rt sets can be represented > without introducing > additional list recipes or delimiter rules, while preserving a clean > extension model. > > * EAI / SMTPUTF8 downgrade hops: a JSON container can carry the original > recipient > identities (including SMTPUTF8 forms) and any downgrade mapping > artifacts in a > structured and unambiguous way. > > * MIME granularity: JSON can naturally encode a MIME tree and carry > per-part hashes. This > enables an MUA (notably in IMAP-based retrieval scenarios) to validate > the DKIM2 > signature once, then selectively validate only the MIME part(s) actually > rendered to the > user. This is particularly relevant for mobile clients and > bandwidth-constrained > environments. > > Considerations: > > This approach requires a well-defined JSON schema (including constraints > on size and schema > evolution) to ensure consistent interpretation across implementations. I > can provide a small > strawman JSON schema that maps cleanly to current DKIM2 concepts. > > Tobias Herkula > > -- > > Senior Product Owner Mail Security > Product Management Mail Transfer & Mail Security > > 1&1 Mail & Media GmbH > E-Mail: [email protected] > Web: www.mail-and-media.com > > Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 7666 > > Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, > Dr. Verena Patzelt > > Member of United Internet > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient of this e-mail, you are hereby notified that > saving, distribution or use of the content of this e-mail in any way is > prohibited. If you have received this e-mail in error, please notify the > sender and delete the e-mail. > _______________________________________________ > 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]
