I think we are 100% in agreement about everything you said here. I also strongly favour a fully reversible recipe, but I acknowledge the tension between that and the wish of various gateways and content protection systems to be able to remove "bad" content without keeping a way to recreate it. Hence the very strong "ONLY use this when you have negotiated a trust relationship with the end recipient of the message".
Bron. On Thu, Sep 10, 2026, at 19:22, MCN-IETF wrote: > 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] >> To unsubscribe send an email to [email protected] >> > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC > [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] > -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
