Hi Hannah, Bron, there is one point about null recipes that I am still trying to understand. I think I understand and agree with the principle that a null recipe should only be acceptable where there is a pre-established trust relationship with the eventual recipient, and that otherwise losing the ability to reconstruct the previous message state should result in significantly lower trust. What I am less clear about is how the receiver is expected to establish that relationship in practice. For example, if a security gateway directly operated by, or explicitly configured for, the receiving ADMD uses a null recipe, the answer seems relatively straightforward: the receiver already knows that this particular signer is trusted to perform destructive content filtering. But what happens if the null recipe appears at an earlier point in the DKIM2 chain? A valid DKIM2 signature can authenticate which signer performed the modification, but it does not seem, by itself, to establish that this signer was authorized to make a destructive modification and discard the evidence needed to reconstruct the previous state. So is the expectation that null recipes should effectively only be accepted from signers explicitly configured as trusted by the receiving ADMD, or could there perhaps be a mechanism for establishing that authorization? I am just trying to understand where that decision is expected to come from.
Best, Pietro -----Messaggio originale----- Da: Hannah Stern <[email protected]> Inviato: lunedì 14 settembre 2026 12:12 A: [email protected] Oggetto: [Ietf-dkim] Re: base64+JSON on the critical path Attenzione: Questa e` la prima volta che ricevi un'email da questo mittente. Attenzione: Assicurati che sia qualcuno di cui ti fidi. Hi! On 9/10/26 22:27, Vittorio wrote: > Hello Hannah, > > I understand the time constraints. But this makes the exchange > circular: you ask for a specific constructive alternative and a > working implementation (which can be found on GitHub), while refusing > to consult the draft that contains both. No. I'm asking for a description of _actual_ problems with the mainline drafts that would ask for an alternative in the first place. > DarkChain is precisely that implementation – written in C, in > production on Sendmail – and the data I cite come from its actual > operation, not from theoretical speculation. It is also the "draft > implementation" you yourself encouraged me to try. You mean the draft implementation of the _mainline_ draft I asked for? (Like not to show to me but to check for yourself if your fears about the mainline drafts is justified.) >> For me, MIME _is_ in the game. Many MTAs handle MIME in some ways. >> E.g. >> for 8BITMIME related transforms - or in mail analysis for spam >> scoring etc. And I can tell >> you, MIME is a beast, even when looking only on what's needed for >> those transforms > MIME and RFC5322 are complex, but they are content the MTA has to > handle anyway. That is not an argument for adding JSON on top for > header changes, where a tag=value declaration does the same job. It doesn't. People working on the mainline drafts/their predecessors proved that. >> I'd personally not hesitate to re-implement the needed JSON subset >> parsing/generation >> manually, with much less qualms than things like RFC5322 address >> header parsing (harder >> than you might think and also showing behavior differences between >> implementations), > In a security protocol that is the concern, not the reassurance. If > each implementer writes their own subset, you get exactly the “parser > differentials” you'd want to avoid - divergent parsing of the same > input, which here is the vulnerability. What _vulnerability_? I don't see a potential exploit if someone is too strict, "just" an interoperability issue that would be sorted out early enough. >> So let's stay realistic with "the internet is for everyone" and >> not assume "everyone" >> includes computing constraints from low- to mid-end consumer >> hardware from more than a >> decade ago (or the expectation that someone who arbitrarily limits >> themselves to a small Z80 >> microcontroller would run an MTA specifically on that)? > The point was never vintage hardware - it was resource exhaustion > under volume. A flat tag=value parser drops malformed input with > near-zero allocation; a structured format has to build the object just > to discover the payload is garbage. Not true. Only a naive implementation will (attempt to) build the object first. It _is_ possible to write a streaming validator for recipe syntax. Just probably for most it'll not be worth it because JSON implementations are actually quite fast. > On a 2GB VPS under a flood of malformed messages, that is the > difference - the "whose CPU" question, not a C64. People would probably rather DDoS your DNS client than manage to DDoS a JSON parser. Even under 2GB VPS constraints. >> You talked about logging. Not about the original representation in >> the mail. Or did >> I misunderstand you? > I was of course also referring to the headers themselves - > self-descriptive headers are, for system administration, a form of > detailed logging that shows how the routing evolved. > >> (e.g. for assessing whose reputation you need to take into >> account) > I understood DKIM2 to be about moving past trust, that is what made it > interesting to me. Yet for two days now the discussion has kept > returning to trust: the null recipe (unavoidable, as I have been > saying for months) and now the asynchronous reputation assessment you > mention. For a model whose premise was evidence over trust, that is > telling. To me it looks as if you might be playing pigeon chess around these issues. Or FUD. People repeatedly described the situations under which null body recipes make sense (with pre-established trust) and that otherwise, their use will probably imply much lower trust than hops that don't opt out of describing their changes. Which is acceptable. Because destructive body cleaning doesn't make sense except if close to sender (a solution for that has been described, involving the security solution signing on behalf of the sender, perhaps involving nd) or close to the recipient (and then the recipient knows that _that_ particular signing domain is trusted to make null body recipes after verifying the mail beforehand). "asynchronous reputation assessment" I mentioned that only as one possible approach if someone is really in fear of synchronous verification. Actually even with synchronous verification there will be more and more asynchronous assessment for completely unrelated reasons that are not the fault of DKIM2, DKIM, DMARC, SPF or whatever. Because giving oneself some more time to assess a mail allows more information (e.g. patterns from other mails received since) to enter spam/... classification. > On header correlation, which you raise in your reply to Richard: > gathering is a protocol requirement, so a JSON solution has to > correlate the same data for the seal. I don't know what you're referring to. "Seal"? "Correlate the same data"? > But it correlates more, and worse: every hop produces its own JSON > recipe, so a verifier must load and reconcile all of them in memory > before it can check anything So what? > and there is no way to work from only the relevant headers. This is > presumably why the mainline leans on light synchronous checks with > heavier verification deferred to an asynchronous back-end. I didn't see it "leaning" towards that. The mainline offers that possibility by ensuring asynchronous bounceability even with shallow checks. But I haven't seen it "leaning" towards asynchronous work. As said, we here will probably do most if not all synchronously, and easily. > A tag=value like DKIM2-Mod, by contrast, lets me roll back one step to > i-1 on the fly, checking that the predecessor did not misdeclare its > header changes, without preloading a tree of recipes or pushing work > downstream. If I want to rewind _one_ step in "mainline" I also have to consider only the r= on the latest (not all) Message-Instance. No need to "preload" all for that. > [...] Hannah. -- Hannah Stern Software Developer Mail Transfer Development 1&1 Mail & Media Development & Technology GmbH | | | Phone: +49 721 91374-4519 E-Mail: [email protected] | Web: https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.mail-and-media.com&e=b336b1a5&h=3428e5a6&f=n&p=y&m=4hk2YD3XVzzGtTm https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.gmx.net&e=b336b1a5&h=dfdb2373&f=n&p=y&m=4hk2YD3XVzzGtTm https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.web.de&e=b336b1a5&h=4954dbe4&f=n&p=y&m=4hk2YD3XVzzGtTm https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.mail.com&e=b336b1a5&h=0de82cdf&f=n&p=y&m=4hk2YD3XVzzGtTm https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.united-internet-media.de&e=b336b1a5&h=400f43da&f=n&p=y&m=4hk2YD3XVzzGtTm Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452 Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr. Verena Patzelt Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. 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] -- Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non infetto. Seguire il link qui sotto per segnalarlo come spam: https://mail2.mcnsrl.it/action/4hk2YD3XVzzGtTm/report-as-bad _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
