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)? Would that count as a dkim2 auth case? Or because the final fromHeader doesn't align it wouldn't count? Are we distinguishing in this proposal between cases where the mailingList made modifications and where there were no changes made?
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]
