Hi!

Can you please keep git in sync?

I find git diff much easier than visual diff between different versions on datatracker in the browser.

Hannah.

On 10/19/26 03:55, Richard Clayton wrote:
In message <179237369481.304694.17403701817247439618@dt-datatracker-
7457c9c988-j45f7>, [email protected] writes

> Internet-Draft draft-ietf-dkim-dkim2-spec-07.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-07.txt
>   Pages:   60
>   Dates:   2026-10-18

There's heaps of tidying up here ... I have spent about 4 man-days (and
a whole heap of $DAYJOB$s tokens getting reviews from Claude) with a
view to making sure everything here is clearly specified and consistent.

I wrote the text BTW, Claude just told me (many times) what was still
wrong with it (until I explained that it was mistaken!)

If you are an implementer the main change is a new signing algorithm,
along with some carefully specified rules for checking the Chain of
Custody which covers a number of lacunae that clearly no-one had
encountered yet with null mail froms and nd=

A high level view of the changes is in the changelog section:

   *  Removed donotmodify and donotexplode.

        there appeared to be WG rough consensus on this

   *  Added the composite PQ algorithm MLDSA44-Ed25519-SHA512.

        as instructed by the interim (but I now think this is not the
        right thing to do, see another message of mine)

   *  Required From header fields to be Authentic

        from the interim

   *  Outlawed duplicate JSON keys.

        long list discussion about JSON but the only spec change to come
        out of that was this restriction (that cannot go in the Schema
        so it is in the text)

   *  Added "u" steps in Recipes to handle non UTF-8 characters. Also
      added patterns to the JSON schema to aid validity checking.

        addresses the issue Hannah raised long long ago and we'd
        overlooked. I didn't use "b" to avoid confusion

   *  Resurrected tag=value definition.

        this seems the simplest way out of the mess

   *  Substantial rework of verification text to ensure it only states
      how to check for a Validly Signed DKIM2 Message, moving
      consideration of what that means into its own section.

        this comes partly from the Authentic From discussion. People
        seemed to want MUSTs etc for signers but Verifiers feed straight
        into local policy, so you will now find that a Verifier just
        tells you if a message is a "Validly Signed DKIM2 Message" or
        not, there are no SHOULD reject statements or similar.

        There are some retrictions on Signers as to what they can do
        with something that is not a "Validly Signed DKIM2 Message" but
        all the MUSTs and SHOULDs in the Verifier spec are solely about
        consistency of reporting flaws in the message.

   *  Substantial rework of the description of DKIM Replay.

        this is now separated from Verification

   *  An EAI section has been added.
   *  A security considerations section has been added.

        please provide text if you want more here

_______________________________________________ > 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]

Reply via email to