+1 Yes, this makes sense, IMHO On Wed, Sep 2, 2026 at 9:00 AM Wei Chuang <weihaw= [email protected]> wrote:
> 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] > -- Al Iverson | Industry Research and Community Engagement Lead Email: [email protected] Phone: (312) 725-0130 (Chicago) Calendar: https://xnnd.com/cal
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
