[Ietf-dkim] Re: I-D Action: draft-ietf-dkim-dkim2-spec-03.txt

[Hannah Stern <[e-mail]>]

Hi!

On 6/24/26 21:08, Richard Clayton wrote:
> In message <178232634716.1360785.12363329888242618970@dt-datatracker-
> f9b87776f-xzl65>, [e-mail] 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; mf=[e-mail] rt=[e-mail]; f=..flags..;
> i=2; d=esp.tld; mf=[e-mail]; rt=[e-mail];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; mf=[e-mail]; rt=[e-mail];f=..flags..;
>
> similarly for a mailbox provider that forwards for vanity domains
>
> i=1; d=example.com; mf=[e-mail]; rt=[e-mail];
> i=2; d=vanity.com; nd=mailbox1.tld;
> i=3; d=mailbox1.tld; mf=[e-mail]; rt=[e-mail];
>
Questions:

- On verification, is it allowed that the latest signature (highest i) 
has nd?

- 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>)?

- 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?

> #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.

> #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.

> #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).

Hannah.

-- 
Hannah Stern

Software Developer
Mail Transfer Development

1&1 Mail & Media Development & Technology GmbH |  |   |
Phone: [phone]
E-Mail: [e-mail] | 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.