The chairs observe a clear consensus in favor, so this document is adopted.
Todd, when you see the notice come in, please submit the renamed -00 version at your convenience. -MSK, for the chairs On Wed, May 27, 2026 at 7:49 AM Todd Herr <todd= [email protected]> wrote: > 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] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
