On 20 Sep 2026, at 10:10, Richard Clayton wrote:
Hash: SHA1
In message <[email protected]>, Pete
Resnick <[email protected]> writes
[Without my chair hat on. This is basically a technical comment, but
I
do think this framing will get it through the process a bit easier.]
On 31 Aug 2026, at 9:32, Richard Clayton wrote:
We update the spec to say that when a From field is first placed
into
a
message (ie it sits alongside an i=1 DKIM2-Signature) or when it is
changed by an intermediary (there is a recipe that shows that it has
been changed at a particular hop) then DKIM2 will insist that there
is
match between the d= domain being used to sign and the domain in the
RFC5322 From header field.
If the group wants to go down this path (and it's sounding like it
does), I would very much suggest that the requirement gets put on the
generator and not on the interpreter:
by which I assume you mean "Verifier"
Yes.
Make the requirement that the
domain in the From: header field MUST sign the message. Then we don't
get into the business of telling receivers what they need to do with
the
message.
we could do this by making the requirement on a Verifier that they MAY
reject the message and MUST NOT forward it outside their org.
The problem is that they may (MAY?) forward it outside their org because
they have independently verified that the message is good even without
the correct signature, or because they have a special relationship with
whoever is getting the forwarded message, or just because they feel like
it. There's nothing, at least from an interoperability standpoint, that
says that they MUST NOT. Maybe you could make the case from a security
standpoint that they MUST NOT, but any responsible receiver of the
forwarded message is going to see the lack of a match between the domain
that signed and the domain in the From: field and ditch the message
anyway. Going down the path of putting requirements on the verifier gets
you into these (admittedly) silly discussions.
Saying that the signer MUST (at least) sign with a key that uses the
same domain name as the "From:" seems like the more straightforward
thing to say.
That way
we have a place to specify a canonical rejection message (which
assists
with interworking / debugging etc)
"Canonical rejection" sounds like an operations thing, not a protocol
thing.
Note that this is an explicit change from DKIM1: In DKIM1,
but not from DMARC ...
DMARC is (ostensibly) out-of-band of DKIM. And DMARC does something
different; it's describing a policy expectation by the sender. I don't
think you want to start down that path in DKIM2.
the semantic
content of the message was explicitly ignored; the only thing it told
you is that some domain signed the message, and it acted strictly at
the
SMTP layer. If we go down this path, in DKIM2 we would be saying that
the signature (or at least one signature) depends on the x22 content
of
the message. I'm not saying that's wrong; I'm simply saying that we
should be explicit about that in the document if this is the path we
choose.
... and it is not a change from what pretty much all email with DKIM1
signatures does today; viz: this is going to actually affect almost
no-
one apart perhaps from really old systems which are not DKIM1 signing
today -- if they are authenticating at all it is by using SPF
I don't disagree, but again let's separate the operations layer from the
protocol layer. It is certainly operationally true that not much at all
is going to change. But it is a pretty significant protocol change.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
