Hi!
(@ all who send HTML formatted mails: Could you please be so kind and
not set font colors/background colors in your mails, they may often
break either on dark mode, dark reader, or on light mode, or on
all/multiple of those, and thus create accessibility issues for some!)
Based on this mail from Tobias plus the said private communication, I'd
suggest these changes to -03 (not fleshed out into good words!):
- In the DKIM2-Signature definition, subsection "nd" (section 8.7 on
datatracker):
Omit most constraints. Just say this declares that there's a special
relation with the next signer, whose "d" MUST match this "nd".
Constraints are described in signer/verifier actions.
- In Signer actions add something like:
If the previous hop specifies "nd", a signer MUST refuse to add a
signature unless it has a signing key for the exactly matching "d"
domain. Its newly applied signature MUST have "d" exactly = that
previous "nd".
In this case, the signer MUST NOT specify "rt"
In this case, the signer MAY omit "mf", but if it specifies one, this
"mf" MUST fulfull the usual constraint for its "d", but need not fulfill
the constraint on any previous "rt" entry.
- In Verifier actions, modify the description of the chain of custody check:
If the previous hop has no "nd" tag:
(Description of usual check, with the added provision that for the
mf/rt check, the latest previously specified "rt" tag applies in case
the directly previous signature has none)
If the previous hop has an "nd" tag:
Verify that the current hop's "d" matches that "nd" value exactly
Verify that the current hop's signature doesn't specify "rt"
Allow missing "mf", but if it's present, check "mf" against "d"
(within this same hop) as usual (relaxed domain match)
Do NOT check this "mf" (if present) against previous "rt"
Kind regards,
Hannah.
On 6/29/26 17:06, Tobias Herkula wrote:
After seeing the discussion between Bron and Hannah and also talking
with Hannah off-list, I re-read the point of the nd= Tag and think the
essence and my intension were mixed up, in my Proposal back from end
of my I wrote:
"If DKIM2 signature i=n asserts the signing domain of DKIM2 signature
i=n+1, DKIM2 signature i=n+1 may omit the mf and rt fields and inherit
their effective values from DKIM2 signature i=n."
But the current text in the draft-03 is kind of referencing the same
signature instead of the previous. And the current wording would not
solve anything for the ESPs involved in this.
--
Best regards,
Tobias Herkula
------------------------------------------------------------------------
*From:* [email protected] <[email protected]>
*Sent:* 24 June 2026 20:39
*To:* [email protected] <[email protected]>
*Cc:* [email protected] <[email protected]>
*Subject:* [Ietf-dkim] I-D Action: draft-ietf-dkim-dkim2-spec-03.txt
Internet-Draft draft-ietf-dkim-dkim2-spec-03.txt is now available. It is a
work item of the Domain Keys Identified Mail (DKIM) WG of the IETF.
Title: DomainKeys Identified Mail Signatures v2 (DKIM2)
Authors: Richard Clayton
Wei Chuang
Bron Gondwana
Name: draft-ietf-dkim-dkim2-spec-03.txt
Pages: 42
Dates: 2026-06-24
Abstract:
DomainKeys Identified Mail v2 (DKIM2) permits a person, role, or
organization that owns a signing domain to document that it has
handled an email message by associating their domain with the
message. This is achieved by providing a hash value that has been
calculated on the current contents of the message and then applying a
cryptographic signature that covers the hash values and other details
about the transmission of the message. Verification is performed by
querying an entry within the signing domain's DNS space to retrieve
an appropriate public key. As a message is transferred from author
to recipient systems that alter the body or header fields will
provide details of their changes and calculate new hash values.
Further signatures will be added to provide a validatable "chain".
This permits validators to identify the nature of changes made by
intermediaries and apply a reputation to the systems that made
changed. DKIM2 also allows recipients to detect when messages have
been unexpectedly "replayed" and will ensure that Delivery Status
Notifications are only sent to entities that were involved in the
transmission of a message.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/
<https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/>
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dkim-dkim2-spec-03
<https://datatracker.ietf.org/doc/html/draft-ietf-dkim-dkim2-spec-03>
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dkim-dkim2-spec-03
<https://author-tools.ietf.org/iddiff?url2=draft-ietf-dkim-dkim2-spec-03>
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
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 [email protected]
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail:[email protected] | Web:www.mail-and-media.com www.gmx.net www.web.de www.mail.com www.united-internet-media.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452
Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr.
Verena Patzelt
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt,
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise
auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient of this e-mail, you are hereby notified that saving,
distribution or use of the content of this e-mail in any way is prohibited. If
you have received this e-mail in error, please notify the sender and delete the
e-mail.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
