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]
