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]
