This whole thread isn't making much sense to me. Let's go back to first principles; and that original example which was hops 4, 5, 6. One can presume that 1, 2, 3 exist and are correct.
Let me paste my text again: i=4 rt=foo@X i=5 d=X; nd=Y i=6 d=Y; mf=bar@Y I acknowledge that I did miss the subdomain alignment between i=4 and i=5; setting that aside. Here are the rules: *i=4* • Does not have an nd=, so the receiving system MUST see an rt= for a domain under its control (foo@X) • In all other respects, is correctly aligned with the previous chain. Enough said. *i=5* • Must be a domain aligned (subdomains allowed) with the rt= from i=4. So call it X' instead of X. • Declares that the next domain will be Y *i=6* • Must be signed with precisely domain Y • Must have an mf= that's aligned with its signing domain (again; subdomains per the spec), so call it bar@Y' I don't see how any of these can not be true and still keep the properties that dkim2 is supposed to provide. ... we really need to say something about "nd is only used when the signer of signature N (with the nd=) and N+1 are the same entity or cooperating out-of-band"; that's the rule; along with the need for alignment. ... I'm happy with MUST NOT specify rt=. That's simpler. Some people want to put rt= there so that the owner of the domain is signing the eventual recipients, and have it MUST match the rt= of N+1. I don't mind that either. I'm happy with not having mf= on the nd= hop. I don't see any possible value it could have to anybody. The ONLY purpose of the nd= hop is to provide connective glue between an incoming domain and a different outbound domain. Bron. On Mon, Jun 29, 2026, at 11:47, Hannah Stern wrote: > 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/ >> >> 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] > -- > 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] > -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
