Hello Richard,
I agree that ambiguity surprises no one, which is why it warrants
normative treatment rather than being left to assumption. The cause is
undeterminable at every hop alike; re-checking does not resolve it.
You have stated the downstream problem precisely and it is an
_interoperability _problem before it is a _policy_ one.
If a message accepted after a non-attributable failure is rejected at
the next hop, then during any real transition - in which
non-participating nodes sit on ordinary delivery paths for years -
strict enforcement rejects everything that has merely crossed such a
node. That is not an edge effect; it is routine loss of legitimate mail,
and it follows directly from the base specification carrying no record
of the failure.
Such a record (which the deployment profile defines) does not tell the
downstream hop that verification failed; it will re-check and see that
itself. It carries, at hop i, the attestation "_the seal was already
broken when I received it, I detected it, and I passed it flagged rather
than dropping it_." Hop i+1 then knows the failure predates its own
handling and that hop i made a deliberate delivery decision, instead of
rediscovering an anonymous failure with only reject-or-accept-blind to
choose from. The failure is localised in the chain and each hop's
decision travels with it. The base specification provides no such
signal, which is why the case is currently unresolved rather than merely
"local policy".
On adoption cost I underline that the rejection itself is the same act
as under DMARC, but the condition for avoiding it is not. DMARC required
one DNS record and no intermediate participation. DKIM2 requires every
hop on the path to participate before strict enforcement stops dropping
legitimate mail. That difference is what turns a transition into routine
breakage, for as long as any non-participating node remains anywhere on
the path.
Regards,
Vittorio Moccia
Il 2026-08-09 18:49 Richard Clayton ha scritto:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Vittorio
<[email protected]> writes
This is the crux and it is worth stating precisely: "content changed
after signing" and "content changed after signing, maliciously"
produce
the same signal, and a verifier cannot tell them apart from the
message
alone.
this should surprise nobody
What seems necessary is a way to record that the most recent signature
failed to verify and to deliver the message anyway
since it would be "local policy" to accept a purported DKIM2 message
which fails verification your local policy could involve writing any
header field you wished ...
... what the DKIM2 spec (that most people here are working on) does not
permit is for you to forward a message accepted by such local policy to
anyone else -- if you did you should expect them to reject it.
the base specification offers no normative guidance for
this class of failure - leaving the accept-or-reject decision to
uncoordinated local policy
if it was coordinated it would not be "local policy"
- --
richard @ highwayman . com "Nothing seems the
same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBanivfmHfC/FfW545EQIxMwCeIbUcUFqiGk7HvuAf0Pyob0KQzTUAn014
DnmAR4m47YKgLsInkNHw3JXr
=+S3C
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
