On Mon, Jun 29, 2026, at 07:51, Hannah Stern wrote: > Hi! > > On 6/24/26 21:08, Richard Clayton wrote: > > In message <178232634716.1360785.12363329888242618970@dt-datatracker- > > f9b87776f-xzl65>, [email protected] writes > > > > > 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 > > > > the changes are (and these affect implementors, so if you own code you > > will need to look at the changes) > > > > #1 introducing nd= as an alternative to mf= rt= for an imaginary hop. > > This is essemtially the "forward" signing scheme that Tobias suggested > > > > viz instead of: > > > > i=1; d=example.com; [email protected] [email protected]; f=..flags..; > > i=2; d=esp.tld; [email protected]; [email protected];f=..flags..; > > > > hide the imaginary hop (because the ESP is creating both signatures) > > > > i=1; d=example.com; nd=esp.tld; f=..flags..; > > i=2; d=esp.tld; [email protected]; [email protected];f=..flags..; > > > > similarly for a mailbox provider that forwards for vanity domains > > > > i=1; d=example.com; [email protected]; [email protected]; > > i=2; d=vanity.com; nd=mailbox1.tld; > > i=3; d=mailbox1.tld; [email protected]; [email protected]; > > > Questions: > > - On verification, is it allowed that the latest signature (highest i) > has nd?
If you're receiving that message over the wire, no... unless you have a contractural relationship with the previous hop. The point is to say "we're managing the handover between domains directly". If you get something with nd= over the wire, it's breaking the replay protections. > - Is it allowed to have more than one nd in a row? (I.e. i=4 has > nd=<domain of i=5>, i=5 has nd=<domain of i=6>)? Yes, no reason why not to. Again, so long as all these domains have contractural agreements. > - How is the mf/rt chain checked in the presence of nd? Just skip the nd > hop? I.e. if i=4 has mf/rt, i=5 has nd, i=6 has mf=rt, do I check i=6 > against i=4 using the usual rules? No, you never skip over a hop. You check: i=4 rt=foo@X i=5 d=X; nd=Y i=6 d=Y; mf=bar@Y Those are the invariants which must pass. > > #2 Sorting out DSNs > > > > There are issues when a DSN flows back along the outgoing path and that > > outgoing path visits the same system more than once (mail does that sort > > of thing from time to time). This is fixed by insisting that DSNs always > > have the header fields present as the email arrived at that hop (so > > remove evidence of forwarding from the DNS that came in and is being > > propagated). Also forbid "null recipes" for headers (which do not seem > > to have a use case) > > This means a) all forwarders _have_ to implement what's needed to > generate the recipes, b) security solutions can't remove my "Virus: > <base64 blob of malware>" field irreversibly. If there's a virus in the header, then you're right - security solutions can't remove it. All they can do is bounce it; which seems reasonable. > > #3 Add the experimental Delivered-To: header field as an exception to > > signing. Also the exceptions are now in a section of their own rather > > than being buried away. > > Stylistically, a simple list of ignored fields would be helpful instead > of digging the list out of prose. > > Rationale could still be provided, e.g. as notes/footnotes to the simple > list/table. Agree, this seems sensible. I'm in favour of a nice sorted list of named header fields. > > #4 Added "feedhere" flag so that privacy preserving forwarders can deal > > with feedback reports (recall -- which are not defined here) do not > > reveal where email was forwarded. > > There's not even a mechanism to give a target for feedback reports (even > with not-yet-specified content format). Yeah, we need to do this! Bron. -- 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]
