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

["Murray S. Kucherawy" <[e-mail]>]

On Tue, Apr 14, 2026 at 12:32 PM Bron Gondwana <brong=
[e-mail]> wrote:

> On the stateful architecture question, the document addresses this in
> Section 4.3. The issue is not database persistence between sessions but
> shared state between filter components within a deployment. To generate
> a body recipe, the signing component needs the message body before
> modification by security gateways, DLP systems, antivirus engines and
> mailing list managers, components that are precisely the most common
> body modifiers and the least likely to implement DKIM2. This state is
> not available through any standard filter interface to a component that
> sees only the final message. Bron Gondwana's implementation in the
> working group interoperability repository requires exactly this
> inter-component state for body recipe generation and this has been
> discussed on the list. DKIM2-core has no such requirement: everything
> needed for signing and verification is available within the current
> transaction.
>
>
> 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.
>

It's workable, but another approach involves knowing a priori what
mutations will occur between a message's arrival and its departure.  One
implementation I did, for instance, could be told "[e-mail] will be
rewritten outbound as [e-mail]" and would then feed the replaced
string to canonicalization, anticipating what actually needed to be signed
versus what arrived over the wire.  Of course, lists are more complex
because they involve multiple mutations and configuring these mutations in
two places might not be practical.

-MSK