A couple things to add/note. Note that although the SPF is ietf.org and DKIM is ietf.org the IETF does not practice fromMunging and so the messages are DMARC failing. So already today, anyone with a p=reject domain that sends mail to the IETF mailing lists faces a lot of undesired rejections by recipients. Note that the current best practice recommendations <https://www.ietf.org/archive/id/draft-ietf-dkim-dkim2-bcp-00.html#section-5.7-1> for DKIM2 is to "Continue doing From munging".
Suppose, though, that the IETF stayed on DKIM1 but adopted fromHeader munging. In this case they have effectively taken ownership of the message. And so if you run a dkim2 aware receiving server you can treat it in line with the current best practices recommendations <https://www.ietf.org/archive/id/draft-ietf-dkim-dkim2-bcp-00.html#section-7.1-5> : “Under certain circumstances a DKIM2-capable forwarder may choose to DKIM2 sign a message with a prior DKIM signature if it can be certain that the message was not replayed or introduce backscatter using local-policy. Some properties to consider are looking for the same anti-replay and backscatter properties described in draft-clayton-dkim2-spec except signed with the DKIM signature. Typically this only is only apparent for DKIM signed messages at origination, meaning when the payload From header is DMARC aligned with the DKIM signed domain and the signature is valid.” Richard, do you agree with that recommendation? If so, it does seem to allow adding a DKIM2 signature and forwarding along provided IETF had done fromMunging to handle this kind of mixed state when initially some groups won't have yet adopted DKIM2. Best, Emanuel On Sun, Aug 9, 2026 at 1:05 PM Richard Clayton <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <[email protected]>, Vittorio > <[email protected]> writes > > >This is the crux and it is worth stating precisely: "content changed > >after signing" and "content changed after signing, maliciously" produce > >the same signal, and a verifier cannot tell them apart from the message > >alone. > > this should surprise nobody > > >What seems necessary is a way to record that the most recent signature > >failed to verify and to deliver the message anyway > > since it would be "local policy" to accept a purported DKIM2 message > which fails verification your local policy could involve writing any > header field you wished ... > > ... what the DKIM2 spec (that most people here are working on) does not > permit is for you to forward a message accepted by such local policy to > anyone else -- if you did you should expect them to reject it. > > >the base specification offers no normative guidance for > >this class of failure - leaving the accept-or-reject decision to > >uncoordinated local policy > > if it was coordinated it would not be "local policy" > > - -- > richard @ highwayman . com "Nothing seems the same > Still you never see the change from day to day > And no-one notices the customs slip away" > > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 > > iQA/AwUBanivfmHfC/FfW545EQIxMwCeIbUcUFqiGk7HvuAf0Pyob0KQzTUAn014 > DnmAR4m47YKgLsInkNHw3JXr > =+S3C > -----END PGP SIGNATURE----- > > _______________________________________________ > 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]
