[Ietf-dkim] Re: Concerns about the recipe/rollback mechanism and deployment architecture in draft-clayton-dkim2-spec

["Inveigle.net" <[e-mail]>]

On 18/03/2026 2:41 am, Vittorio wrote:
> On deployment realism
> DKIM2 as specified requires meaningful intervention at every node in the 
> delivery chain — not just MTAs, but forwarders, mailing list managers, 
> antispam and antivirus gateways and any other software that adds or 
> modifies headers or bodies. The fact that work is already underway to 
> modify Sympa and Mailman illustrates this concretely. However, the 
> Internet is not composed solely of large providers. A substantial 
> portion of email infrastructure is operated by small ISPs, universities, 
> research institutions, and small businesses for whom a simultaneous and 
> significant technology upgrade of this magnitude is either very slow or 
> simply not feasible. An architecture that requires all nodes to change 
> at once to function correctly is not a network architecture, it is a 
> closed system.

Unfortunately, there has been very little engagement from people on the 
list regarding these concerns. Those I have talked to off the list, 
including SMTP implementers and operators absolutely do share these 
concerns.

> On MTA-level integration requirements
> A further deployment concern is architectural. DKIM2 validation is 
> specified to occur during the SMTP transaction itself — specifically, 
> the envelope binding (mf=/rt= matching against MAIL FROM and RCPT TO) 
> and the 4xx/5xx rejection logic must happen before or during the DATA 
> phase response. This makes the protocol fundamentally incompatible with 
> the milter interface and equivalent plugin architectures (such as 
> Sendmail/Postfix milters, or content filters that operate post-DATA).
> Milter-based solutions are precisely the mechanism by which the existing 
> ecosystem has absorbed DKIM1, DMARC, ARC, SPF checking, antispam and 
> antivirus processing without requiring modifications to core MTA 
> codebases. They represent the extension point that allows small 
> operators to deploy new mail authentication features incrementally and 
> independently of their MTA vendor's release cycle.

As you have hinted at, the changes required in support of the current 
approach are not simply a matter of upgrading the MTA. They would 
require significant architectural changes to many mail systems to the 
extent that they would affect the viability of many smaller operators.

The scope also isn't limited to SMTP itself, as DKIM2 as proposed is not 
a superset of DKIM and does not cater to all existing use cases, in some 
cases necessitating logic changes in scripts that make use of SMTP for 
delivery.

I am not convinced there is any need for mf= or MAIL FROM rewriting at 
all. In the absence of mf= and rollback, the remaining objectives of 
DKIM2 could be implemented as a single call to the milter or filtering 
interface if a simple SMTP extension is used. The requirements can be 
met with the existing milter 6 feature set. This avoids an O(N) 
regression on signing, delivery and storage and caters to existing use 
cases. However, any proposal to use an extension is met with responses 
such as this...

"SMTP extensions are an order of magnitude harder than something that 
just operates on the message", followed up with "that's impressively 
optimistic."

Such comments are disappointing when you consider the extent of 
architectural changes and amount of code necessary, across a diverse 
range of systems, necessary to support the claimed 'simple' approach.

These views are also not consistent with those of SMTP implementers I 
have discussed this with, with all indications being that an extension 
would be easy to implement.

 > I would genuinely like to understand what specific threat or use case
 > the recipe/rollback mechanism addresses that draft-chuang-replay-
 > resistant-arc did not, and why the decision was made to move toward a
 > significantly more complex architecture rather than building
 > incrementally on that prior work. If that discussion has already
 > happened on this list I apologize for the redundancy and would welcome a
 > pointer to the relevant thread.

The motivations for all features beyond replay protection are, in my 
view, poorly justified. Relay protection, DKIMs biggest weakness, is 
easily solved with an extension and the mailing list/privacy forwarder 
mitigations represent a solution in search of a problem. Fixing broken 
software that is not compliant with existing RFC requirements or 
intended behaviour, while tightening up the DKIM validation rules, would 
solve most issues.

Regards,
R. Latimer
Inveigle.net