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?
- 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: +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]
