Hello,
How do you propose to do that? and which of the aims of this working
group will you ignore as you proceed?
None of them and the how follows directly.
The transition is handled by not rejecting good mail on a failure whose
cause cannot be determined. When b= verifies, the signing node's
signature is genuine and its own declaration is not in question. But
content outside that guarantee can still change. In that case the
verifier cannot tell a non-participating legacy node from an attacker
exploiting the same absence.
This is where it differs from ARC and answers the trust objection raised
earlier. I am not asserting the hop was good. I am recording that
something failed and that its cause cannot be determined. There is no
assertion to trust: a node attests to the outcome of its own
verification, not to what happened upstream, and claims nothing about
prior state. Attestation of flow, not reconstruction of it.
The mechanism does not remove replay protection; it graduates the
response to it as adoption rises. Detection is constant throughout: the
envelope binding fails a changed recipient every time, and that failure
is always recorded. What changes is what a receiver does with it, in
three steps:
- First, observe: results are recorded, nothing is rejected.
- Then reject what only a DKIM2 participant could have produced: a
structural failure or a node that signed validly yet declared
modifications its own signature proves it misrepresented - neither of
which an innocent legacy node can cause. A failure whose cause cannot be
determined - where a legitimate forward and an attacker are the same
signal - is carried forward flagged rather than discarded blind.
- Finally, once adoption is high enough that an undetermined cause can
no longer plausibly be a legacy hop, that too is rejected.
That final step is the full rejection this working group wants - reached
by a path that does not destroy legitimate forwarding while the
installed base is still converting. The trigger for moving between steps
is the one you named yourself: the proportion of mail that is
DKIM2-signed.
And the recorded result is what lets local policy do what a binary
reject cannot: decide what the final user is told - deliver with a
marking, file it differently, warn - rather than silently discarding
mail the user may have needed.
That is the proper place for local policy: not deciding whether two
implementations interoperate, but deciding how to present, to its own
users, a result the protocol has made legible. The choice is not between
replay protection and accepting anything; it is between rejecting blind
and rejecting informed.
Regards,
Vittorio Moccia
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
