[Ietf-dkim] Re: New I-D: A Deployment Profile for DKIM2 via Milter Interface

[Vittorio <[e-mail]>]

Bron,

> Correct - SOMETHING has to be able to calculate the difference between 
> the old and
> new body if you're going to do body recipes. My "take a copy on the way 
> in, compare
> on the way out" approach is the dumbest thing that could possibly work; 
> it's great
> for demos.

Agreed, and this is precisely the architectural concern documented in 
Section 4.3. The question is not whether a demo works but whether the 
mechanism scales to production deployments where the modifying component 
and the signing component are separate systems - security gateways, DLP 
engines, antivirus systems - with no shared state and no common code 
base.

> You'll also note that my mailman and sympa patches do the calculation 
> inside
> the software

This moves the requirement from the milter to the MLM core. It does not 
eliminate it. Every MLM that wants to participate in DKIM2-extended body 
accountability must be patched. The closed source software - Exchange, 
Notes, commercial security gateways - cannot be patched by anyone except 
the vendor. This is a deployment timeline constraint, not an engineering 
complexity one.

> I would have been more sympathetic to your argument even a year ago, 
> but with a
> good spec, even the existing agentic software builders are bloody good, 
> and
> they're only going to get better.

The hackathon produced three confirmed interop failures between 
independent implementations of the same spec - implementations that were 
partly AI-generated, as documented in your own hackathon report of 14 
March 2026. A spec with ambiguous ordering rules, invalid JSON schemas 
and inconsistent limits produces interop failures regardless of the 
quality of the implementation tools. Agentic builders can reduce the 
cost of writing code - they cannot reduce the runtime cost of an O(n·m) 
architecture or expand the 32KB header buffers of the legacy servers 
that form the backbone of enterprise and government email. 
Interoperability is a property of the installed base, not of the newest 
open-source patches.

> Your proposal doesn't do that, and the people dealing with large 
> volumes of incoming
> mail want attribution

DKIM2-core does attribution. Every hop signs with its own domain. The 
bh= value changes when the body is modified and the signing domain at 
the modifying hop is identified in the chain. DKIM2-Mod declares header 
modifications explicitly. What moves the needle on attribution is the 
chain of custody - knowing that the message passed through identifiable 
hands with cryptographic proof. Body recipes do not change the trust 
decision - they document modifications that the chain of custody has 
already attributed to a specific signing domain. As documented in 
Section 7.1, if the receiver does not trust the intermediary, no recipe 
makes the content safe. If the receiver does trust the intermediary, the 
chain of custody is sufficient.

A broader point on interoperability: the requirement to patch MLMs, 
security gateways and antivirus systems to generate body recipes is 
itself an interoperability constraint. Interoperability is not only a 
property of the wire format, it's a property of the entire delivery 
chain. A protocol that requires coordinated modifications across 
components that have independent development cycles, proprietary 
codebases and different deployment timelines imposes a deployment 
barrier that is architecturally equivalent to a core MTA modification. 
The null recipe is not a safety valve: as documented in Section 4.5, 
systematic null production at precisely the nodes most likely to modify 
message bodies undermines the accountability guarantee that body recipes 
are designed to provide.

Regards
Vittorio Moccia