Thank you for your detailed comments, Hannah. As others have mentioned, this document at this stage is just a starting point, and i anticipate that if the working group adopts it, it'll go through many revisions before its possible publication.
As editor, I kindly request that if and when the document is adopted, issues for it be created in the Github repository that's been established for this group's work. I believe https://github.com/dkim2wg/spec to be the proper URL for all documents that this group has adopted, but I'm willing to be corrected on that matter. On Tue, May 26, 2026 at 10:27 AM Hannah Stern <hannah.stern= [email protected]> wrote: > Hi! > > On a first glace the document looks good to adopt on. > > In terms of merits the first glance sections 2.3 together with 5.3 may > be difficult. > > Either we define a forwarder specifically as a site that changes the > envelope, or we can't require forwarders to sign each message regardless > if they make changes. > > DKIM2 itself supports 3 cases: > > - Unchanged message/envelope: No signature needed, probably not even > possible because the intermediate relay may not be in the same domain as > the original envelope sender. > > - Unchanged message/changed envelope: New signature needed as per the > "base" spec, requiring a new envelope sender even if the use case itself > would be only a recipient change > > - Changed message/changed envelope: A Revisor wants to change the > message. The intermediate has to "own" the changes and thus _has to_ > change the envelope not only as best practice but as technical need. > > - IMPOSSIBLE: Changed message/unchanged envelope: Unless the Revisor is > in the same domain so it can leave the envelope unchanged and still sign > with d=/mf= alignment and a new Message-Instance. > > In section 6, I think the classification can be done even if the > "unchanged message/envelope" kind of relays don't add signatures. > > - Any DKIM2 signature there and the whole chain validates? -> 6.1; any > DKIM2 signature otherwise -> 6.2. Otherwise 6.3. > > (Though I'm not sure how a Verifier could distinguish the case that the > whole chain validates between a) sender applied signatures and mail > never left the DKIM2 world, or b) some intermediate started adding DKIM2 > signatures, but from then on all others also did where needed. Perhaps > that's checking From alignment between the i=1 state of the headers, and > the i=1 signing domain.) > > 7.2 I'm not sure if DKIM2 completely obviates DMARC. The main spec for > DKIM2 currently doesn't define alignment between From and one of the > signing domains. (The From at i=1 would have to match the d= at i=1, > afterwards, the from of any i=<i> would need to match the signing domain > of the Revisor which introduced this version of the From field.) > > Kind regards, > > Hannah. > > On 5/22/26 21:39, Murray Kucherawy via Datatracker wrote: > > This message starts a dkim WG Call for Adoption of: > > draft-herr-dkim2-bcp-01 > > > > This Working Group Call for Adoption ends on 2026-06-05 > > > > Abstract: > > [DKIM2] and associated documents describe the DomainKeys Identified > > Mail v2 (DKIM2) email authentication protocol. DKIM2 is designed to > > address shortcomings in email authentication protocols and mechanisms > > released prior to DKIM2, specifically SPF [RFC7208], DKIM [RFC6376], > > DMARC [RFC7489], and ARC [RFC8617]. Those shortcomings most commonly > > manifested themselves in email messages that passed through one or > > more intermediary hosts (e.g., forwarders or mailing list servers) > > while transiting from origination to final destination. Although > > these messages were properly authenticated when sent, the alteration > > of their path and/or content by the intermediary hosts would cause > > authentication checks to fail at the final destination. In addition, > > DKIM was susceptible to "replay" of signatures, when attackers would > > construct abusive messages in such a way that they would pass > > validation checks for a DKIM signature that had been imported from > > another message entirely. > > > > To address these shortcomings, DKIM2 provides methods not only for > > intermediary systems to provide details of the changes that they make > > to a message in transit, but also for receiving hosts to validate > > those changes in addition to the original message. DKIM2 also allows > > recipients to detect when messages have been unexpectedly "replayed" > > and can also ensure that delivery status notifications (DSNs) are > > only sent to entities that were involved in the transmission of a > > message. > > > > This document describes the recommended usage of the DKIM2 protocol > > for sending hosts, intermediary hosts, and receiving hosts. > > > > Please reply to this message and indicate whether or not you support > adoption > > of this Internet-Draft by the dkim WG. Comments to explain your > preference > > are greatly appreciated. Please reply to all recipients of this message > and > > include this message in your response. > > > > Authors, and WG participants in general, are reminded of the Intellectual > > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > > Appropriate IPR disclosures required for full conformance with the > provisions > > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > > Sanctions available for application to violators of IETF IPR Policy can > be > > found at [3]. > > > > Thank you. > > [1] https://datatracker.ietf.org/doc/bcp78/ > > [2] https://datatracker.ietf.org/doc/bcp79/ > > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-herr-dkim2-bcp/ > > > > There is also an HTMLized version available at: > > https://datatracker.ietf.org/doc/html/draft-herr-dkim2-bcp-01 > > > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-herr-dkim2-bcp-01 > > > > _______________________________________________ > > 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] > -- Todd
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
