Hi Bron, I think this is exactly the point that makes me uncomfortable with null body recipes, at least if they are considered a normal alternative to preserving the information needed to reconstruct the previous message state. If the choice is between preserving enough evidence to reconstruct what an intermediary removed, and discarding that evidence so that the receiver has to trust the intermediary, I would strongly prefer the former whenever possible. This does not mean that potentially malicious content should be reconstructed and delivered to the user's mailbox. The receiving system can decide whether and how to reconstruct it, analyse it in a controlled environment, quarantine it, or never expose it to the user at all. But it still has the possibility to determine for itself what was actually removed. Otherwise, as you say, the receiver cannot distinguish between a legitimate antivirus gateway removing malicious content and a malicious intermediary removing or replacing legitimate content. In that case we have deliberately replaced verifiable evidence with the reputation or trustworthiness of the intermediary. To me, deciding whether some content is malware and what to do with it belongs to the receiving security policy, not to DKIM2. What I would expect DKIM2 to preserve, whenever possible, is the evidence that allows the receiver to verify what happened. So perhaps a null recipe is sometimes an unavoidable escape hatch, but I would not consider it equivalent to a reconstructable recipe. It represents an explicit loss of verifiability, and I think that distinction should be clear to the receiver.
Best, Pietro Da: Bron Gondwana <[email protected]> Inviato: mercoledì 9 settembre 2026 13:07 A: [email protected] Oggetto: [Ietf-dkim] Re: base64+JSON on the critical path Correct, which is why Antivirus gateways need to have a relationship with the eventual recipient. If you run an antivirus gateway and remove the content, then forward it on, you're in a state of sin. Maybe you're really a good actor, just cleaning viruses. Maybe you're a scumbag, replacing the content with your own material. Nobody can tell, so they have to trust you. So you'd better be on (as Richard says) their Christmas Card list. Bron. On Wed, Sep 9, 2026, at 19:46, Vittorio wrote: Hello Bron, Allen Robinson stated on this list that null recipes "reintroduce the concept of trust to DKIM2" and cited this as a strong reason not to support them. Your description ("switches from evidence based to trust me") confirms his assessment. The mechanism the specification relies on for antivirus, DLP and encryption gateways is, by its authors' own acknowledgment, a reversion to the trust model DKIM2 was designed to replace. Regards, Vittorio Moccia Il 2026-09-08 15:11 Bron Gondwana ha scritto: > On Tue, Sep 8, 2026, at 17:47, Vittorio wrote: > >> On malware I agreed, the libraries aren't the exposure. But I still >> haven't seen how a body recipe avoids carrying downstream exactly >> what >> an antivirus gateway stripped. Antivirus usually operates at the >> edge, >> but the same edge serves both local reception and onward relay to >> other >> systems. > > This is what the null body recipe is for. It is canonically > impossible to both suppress the data the antivirus gateway stripped > AND make it possible to recreate the previous message in a way that > the hash of an earlier Message-Instance header will still match. > > The alternative, as ARC has demonstrated, is a trust-based system > rather than an evidence based system. The null body recipe is just > that, a way that switches from evidence based to "trust me". > > Bron. > _______________________________________________ Ietf-dkim mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]<mailto:[email protected]> -- Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non infetto. Clicca qui per segnalarlo come spam.<https://mail2.mcnsrl.it/action/4hfyhm3pV2zGxw4/report-as-bad> Clicca qui per metterlo in blocklist<https://mail2.mcnsrl.it/action/4hfyhm3pV2zGxw4/blocklist>
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
