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/ There is also an HTMLized version available at: 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 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 to [email protected]
