On Tue, May 13, 2025 at 3:24 AM Alessandro Vesely <[email protected]> wrote:
> On 12/05/2025 17:50, John Levine wrote: > > It appears that Alessandro Vesely <[email protected]> said: > >>> When you deliver a message, if you want to undo that particular change > to make > >>> it easier to reply to list messages, that's not a bad idea, and it's > something > >>> I've been doing for years on my mail system. > >> > >> Yup, it's a curious protocol. The forwarder munges From: and the > receiver > >> restores it, after DMARC evaluation. (Maybe someone should specify > what header > >> field to use, Original-From:, X-Original-From:, Author:,...) > >> > >>> But it's not related to DKIM2*. > > > > Let us not forget that one of the goals of DKIM2 is to make this kind of > munging > > unnecessary. > > > I also thought this was the desired solution to the mailing list > problem. In fact, since a DKIM2 verifier can verify the original > signature of the author's domain, it can issue a dmarc=pass in the face > of admissible transformations. > > However, how does a list know which subscribers have a DKIM2 verifier? > We should still stick to the curious, though improved, protocol above. > > Wrapped in this question is the issue of interop between DKIM2 and DKIM1 world. When I first heard of DKIM2, I think Bron and Richard proposed a workable end state scheme where DKIM2 forwarders (with a DKIM2 message) would check the receiver's DKIM2 capability via a SMTP extension that declares DKIM2 support. If the receiver does not support DKIM2, then the message would be rejected/bounced by the forwarder. With such strict mail handling, you would know all receivers support DKIM2 authentication, and the From header rewriting would not be necessary because you know all receivers support DKIM2. My concern with this scheme is that when first launched there will be many receivers that do not support DKIM2 which either causes deliverability problems. Their counter proposal was to resent the bounced messages in DKIM1. Another alternate method is to support both DKIM2 and DKIM1 as implied throughout this thread. Forwarders that modify messages with a DMARC consequence will also have to DKIM1 resign and rewrite the From to take ownership of the message. Potentially the DKIM2 message algebra can retain the original DKIM-Signature if deleted today, so that it can be restored, and the DKIM1 results leverage the DKIM2 algebra reversal. If the receiver does not support DKIM2, the message falls back to DKIM1. The upside is compatibility with DKIM2 and DKIM1 meaning it doesn't have the deliverability impact or extra bounce/retry of the above technique. However, the tradeoff is more complexity and AFAIK there is not a smooth transition. Each sender will have to make up their own mind as to when to switch DKIM2 only (without the From rewriting) on their own. -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
