I propose this concept get written up as an Internet-Draft. Please chime in if you think this approach of defining policy, including updating DMARC, makes sense or doesn't. -Wei
On Sat, Aug 29, 2026 at 2:13 PM Wei Chuang <[email protected]> wrote: > Sorry for the delay in responding. > > On Wed, Aug 26, 2026 at 1:39 PM Emanuel Schorsch <[email protected]> > wrote: > >> Thanks Wei for writing this up, I think it's very helpful! Can you spell >> out how this would work for the sender -> mailingList (no fromHeader >> modifications) -> receiver use-case (assuming they all support DKIM2)? >> > > Sure. This is the mailing-list scenario, all within DKIM2, i.e. the flow > is: Originator -> Mailing List -> Destination > > The following are the headers after Mailing-List: > > From: [email protected] > > DKIM2-Signature: i=1; d=originator.example; [email protected]; > [email protected]; > > DKIM2-Signature: i=2; d=mailinglist.example; f=unaligned; > [email protected]; > [email protected]; > > At origination, this still recommends aligning at origination i=1. At the > mailing-list i=2, although the payload From header could align, it does not > in this example, and the "unaligned" flag indicates this is intentional. > > Would that count as a dkim2 auth case? >> > > In this proposal, yes, because all changes are attributed to a signer and > the changes (none) are identified. Alignment is also attributed. > > >> Or because the final fromHeader doesn't align it wouldn't count? >> > > As mentioned, alignment is attributed in this proposal. > > >> Are we distinguishing in this proposal between cases where the >> mailingList made modifications and where there were no changes made? >> > > This proposal still uses recipes as described in the -06 draft so mailing > list changes can be attributed. Thus, a message that a mailing-list adds a > footer or modifies the Subject header field can be DKIM2 authenticated. > -Wei > > >> >> Best, >> Emanuel >> >> On Wed, Aug 26, 2026 at 10:49 AM Wei Chuang <weihaw= >> [email protected]> wrote: >> >>> DMARC combines a sender's enforcement policy published via DNS plus the >>> concept of what is to be validated which is around payload From alignment. >>> DKIM2 defines two sender defined forwarder constraint policies with the >>> flags "donotmodify" and "donotexplode". This bifurcation is confusing >>> because they seem to work in a disjoined way. Further there have been >>> several discussions on the list about flags, DMARC and compatibility of >>> DKIM2 that exists to DKIM1 and back to DKIM2 world. IMO these topics are >>> all interrelated and we should think about this holistically across DMARC >>> and DKIM2. DKIM2 authentication is meant to replace both DKIM1 and SPF, >>> and with that an opportunity to refine the utility and security of these >>> policy mechanisms. >>> >>> We propose separating out the sender's constraint/validation policies >>> from the enforcement policy, and to make consistent where to read >>> policies. With DKIM2, we propose constraint/validation policies are placed >>> in the DKIM2 flags as these are configurable per message. The DKIM2 draft >>> already specifies two sender policy constraint/validation flags- >>> "donotmodify" and "donotexplode". This also proposes that the DKIM2 >>> "feedback" flag has a modified meaning. DMARC reporting is always enabled >>> for i=1 DKIM2 signer if aligned and a DMARC feedback policy record is >>> present to match current DMARC RFC9989 behavior. However for i>1 by >>> default no reporting is given. That may be overridden by setting the >>> "feedback" flag to explicitly request DMARC feedback for any i and any >>> alignment and so long as there is a DMARC feedback policy record published >>> for that domain. >>> >>> This proposes a third flag to control the DMARC RFC9989 alignment >>> validation behavior. By default it is always applied at each hop >>> corresponding to some DKIM2 signature, however if the "unaligned" flag is >>> published, then no DMARC alignment validation is applied on. Alignment >>> implies "ownership" of the message, as the payload From address is updated >>> to be an aligned sender. When "unaligned" is set on the i=1 DKIM2 >>> signature, this may be used when the message originated elsewhere as a >>> "DKIM1" message but entered into the DKIM2 system at the i=1 DKIM2 signer, >>> and the i=1 signer declines to take "ownership" of that message. >>> >>> Now we describe the changes to sender's enforcement policy. With this >>> change, there is still a need for a published DNS policy as it acts as a >>> side-channel outside of the message indicating the sender's enforcement >>> policy goals. This is important as a message may not contain DKIM2 >>> signatures for example if it is a spoofed message of the sender or was >>> modified to remove the signatures. This proposes using the DMARC RFC9989 >>> p= and sp= policy record tags for DKIM2. These tags can take the value as >>> defined by RFC9989. >>> >>> - >>> >>> reject >>> - >>> >>> quarantine >>> - >>> >>> none >>> >>> However DMARC alignment behavior is modified by DKIM2 signature header >>> field "alignment" flag as noted before. This recommends implementing the >>> other RFC9989 tags without further interpretation. >>> >>> To permit an MTA to publish what authentication methods it supports, >>> this also proposes a new optional DMARC policy record tag "auth=". This >>> flag provides a declaration of authentication methods supported as both a >>> SMTP MTA sender and receiver, meaning what authentication methods >>> potentially present in the messages when sent, and what authentication >>> methods it will process as a receiver. "auth=" takes a comma separated >>> list of supported authentication methods: >>> >>> - >>> >>> dkim >>> - >>> >>> dkim2 >>> - >>> >>> spf >>> >>> >>> If not specified, relying parties can assume that both DKIM1 and SPF are >>> supported. Notably by default DKIM2 is not specified. If "auth=" is >>> supplied, then DKIM2 is meant to be explicitly declared so that it can be >>> used as a capability mechanism. "auth=" can also be used to declare that a >>> MTA does not support some authentication method. Because this declaration >>> is optional, MTAs may choose not to use this tag but still support an >>> authentication method such as DKIM2. >>> >>> Because the "auth=" tag can serve as a DKIM2 capabilities publication >>> mechanism, a DKIM2 sender can check if a receiver supports DKIM2. If the >>> receiver does not, the sender can choose to bounce the message, or continue >>> to forward anyways. If it forwards the message, it risks a subsequent >>> DKIM2 receiver detecting the incomplete chain of custody and rejecting >>> those messages as they are indistinguishable from replay. Instead the >>> sender can choose to delete all DKIM2 signature header fields, or we >>> propose a second alternate declaration mechanism. When a sender wishes to >>> indicate that a message is going from DKIM2 to DKIM1 and to stop testing >>> the envelope recipient against the DKIM2 signature, it can publish a DKIM2 >>> signature header field "rt=" tag without envelope recipient addresses. >>> Subsequent DKIM2 receivers can see that a message was intentionally sent to >>> a non DKIM2 domain, and that replay checking is unnecessary. This >>> essentially allows all DKIM2 receivers to deterministically apply >>> anti-replay enforcements without solely needing to rely on local policy. >>> Those DKIM2 signature header fields provide value to subsequent DKIM2 >>> receivers even after the message passes through a DKIM1 forwarder. That >>> subsequent DKIM receiver can still process the DKIM2 signature header >>> fields for delivery forensics including the message traversed DKIM1, >>> respect the "donotmodify" and "donotexplode" policies, and provide DMARC >>> feedback as it wishes. >>> >>> DKIM2 participants should be very careful about using these features >>> that enable interop between DKIM1-only participants due to the potential of >>> introduced replay risks. This is particularly true when a DKIM2 >>> participant accepts DKIM1 traffic and signs as a DKIM2 message. It is >>> incumbent on the DKIM2 forwarder that introduces DKIM1 traffic that the >>> traffic is free of replay because downstream receivers cannot use DKIM2 >>> "rt=" to prevent replay. We suggest that these DKIM1 interop features >>> should be limited to DKIM2 bring up and when the DKIM1-only participant is >>> well understood such as legacy enterprise services. We recommend not >>> extending the DKIM2 signature chain if a message leaves DKIM2 to DKIM1-only >>> forwarder and returns to a DKIM2 receiver. It should be noted that if a >>> DKIM1-DKIM2 forwarder fails to protect against replay, it is well >>> identified by its DKIM2 signature. >>> >>> The following are examples to illustrate the above concepts. >>> >>> #1 DKIM1 -> DKIM2 (unaligned, reporting requested) >>> >>> From: [email protected] >>> >>> DKIM-Signature: d=originator.example >>> >>> DKIM2-Signature: i=1; d=forwarder.example; f=unaligned,reporting; >>> [email protected]; [email protected]; >>> >>> #2 DKIM2 -> DKIM1 -> DKIM2 >>> >>> From: [email protected] >>> >>> DKIM2-Signature: i=1; d=originator.example; [email protected]; >>> rt= >>> >>> >>> -Wei >>> >>> _______________________________________________ >>> 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]
