Hello Richard,
thank you. I want to hold onto the point you conceded, because it
generalises beyond the example. DKIM2 signs inclusive of the envelope,
the intended recipient among it, for replay protection: a message
delivered to a recipient other than the one it was signed for no longer
verifies. Forwarding does exactly that: it redirects the message to a
different recipient. A DKIM2-aware forwarder declares the change and
signs the new hop, so the chain holds.
A non-participating node changes the recipient without declaring it,
because it cannot, and the signature fails at the DKIM2-aware receiver -
necessarily - not through malfunction, but because the mechanism cannot
distinguish a legitimate forward from a replay. SRS is one visible form
of this (envelope rewriting, default on major platforms); a plain
forward without SRS is another, breaking the chain the same way and, in
addition, failing SPF - which quickly degrades sending reputation. The
specific mechanism matters less than the fact that, for as long as a
non-participating node sits on a path, an intact message can arrive as a
broken chain through no fault of the sender.
That "for as long as" is the real point and it raises a question of
principle, not of convenience.
Interoperability is what a standard exists to provide: implementations
from different parties, at different stages, working together.
Whatever the adoption rate, there will be a long period in which DKIM2
and non-DKIM2 nodes share delivery paths: this is what every
email-protocol transition has looked like. During that period, a
protocol whose enforcement rejects any message that has crossed a
non-participating node does not interoperate with the installed base. It
interoperates only with itself.
You confirmed this: a valid message forwarded through a legacy node
cannot be delivered to a DKIM2-aware destination. This is not an
inconvenience to be waited out; it is non-interoperability during
coexistence and "adopt it universally" is not an answer, because
interoperability has to hold while adoption is under way, not only once
it is complete.
SRS is worth naming only for the scale it makes concrete: it is default
behaviour on major platforms, not a rare misconfiguration, and it is
precisely what is harmless to DKIM1 - which does not cover the envelope
- yet breaks DKIM2, which binds it. I am not asking that SRS be
documented or that publication wait on it.
Mailing lists are another, and I would not set them aside too quickly -
we are, after all, conducting this discussion on one. They are not an
edge of the system; for much of how standards are made and how
communities communicate, they are the system.
"Adopt the standard" describes the destination; interoperability is
required for the journey. DMARC's "adopt it", as I have noted before,
was a single DNS record, required nothing of intermediaries, and even so
took years remains incomplete and broke lists along the way. DKIM2's
"adopt it" is software on every forwarding node in the path - a
different order of task, and therefore a longer journey, during which
the installed base is exactly what the protocol must still interoperate
with. Applying "reject on a broken chain" for that duration is not a
transition strategy; it is designed non-interoperability with the
existing mail system, for as long as any part of it has not yet
converted.
None of this requires trusting an intermediary's account of the past,
that was ARC's bargain, and I share your reservations. A per-hop record
stating only "at my hop, verification of the prior signature failed" is
an attestation a node makes about its own verification, not a claim
about upstream history. It reconstructs nothing and needs to know
nothing about what a legacy node did. It lets the next hop carry the
message forward flagged rather than reject it blind: for the length of
the transition, a broken participant and a legacy non-participant
produce the same signal and rejecting on a cause that cannot be
determined discards the legitimate along with the rest. That is what
designing for the transition, rather than assuming it away, actually
means.
Regards,
Vittorio Moccia
Il 2026-08-27 16:29 Richard Clayton ha scritto:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Vittorio
<[email protected]> writes
A legacy forwarder that is not DKIM2-aware and performs SRS rewrites
the
envelope MAIL FROM, as it has done for many years to preserve SPF
across
forwarding.
SRS is not documented in any RFC, so from the IETF's point of view it
is
anyone's guess what is going on ...
... but I believe it be commonly accepted that the forwarder will not
use the MAIL FROM which was used to send the message to it but will
instead ensure that an SPF lookup on the domain part of the MAIL FROM
that it is using will get a "pass"
Note that this will not be an "aligned pass" so it will not help you
with DMARC ... it's only useful when talking to receivers who insist on
any kind of SPF pass
It does not receive a broken message; it breaks a good one, by doing
exactly what SRS has always done.
You are correct ... a naive system that receives a perfectly good DKIM2
message and transparently forwards it, changing nothing but the RFC5321
MAIL FROM, will not be able to send it to a DKIM2 aware destination
So we should probably put a sentence into the BCP telling people not to
do that ! except that if they are not doing DKIM2 I wonder if they
would ever read it.
Now you might think that because of the other (totally undocumented in
the way that the IETF would understand it) parts of the SRS string that
a receiver could reconstruct the previous MAIL FROM ... if you want to
go down that route then you would block publication of DKIM2 as we
waited for SRS to be properly documented (if indeed there is any
consensus on the detail, and whatever caused it not to be documented in
the first place is not still a show-stopper).
I think that documenting SRS to be able to leverage what it reports is
likely a waste of a considerable amount of time.
Instead, upgrade the system that is using SRS to only send it to the, I
believe, relatively small number of receivers who consider an unaligned
SPF pass to be of value... or better yet, upgrade the system to be
DKIM2
aware and then you can declare that you are doing SRS and provide
attestation (including the "invisible hop" stuff if you need it) that
your actions are cryptographically sound.
Structurally this is the same as a non-DKIM2
list rewriting a Subject:
not really ... we've got some robust documentation (that will shortly
be
available at "standard" level) for header fields
The claim that forwarding is negligible by volume mistakes what
forwarding is.
It is not a class of sender that appears as a line on a dashboard
I assure you that it is at $DAYJOB$ ... and quite a long way down...
Also when customers report that forwarding is failing (either to our
system or away from our system) we strongly encourage them to use IMAP
to collect their email from their <n> accounts (something modern
software does out-of-the-box) rather than forward email through one or
more systems to one central location. Spending our time persuading
remote systems to reconfigure to deal with edge cases in forwarding is
generally ineffective -- and systems that forward to us without any
effective controls on volume or content rapidly find that their flows
are throttled or disabled altogether.
So yes, I will agree with you that forwarding does occur and the people
whose email is forwarded place value in that happening. However, to
suggest that it currently works extremely well and DKIM2 is going to
make the situation worse does not accord with what I see going on.
- --
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"
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
