This is great -- thanks. I think this is necessary. I'll go hunting for nits to provide feedback on and hope that others will do the same.
Cheers, Al Iverson On Sat, Sep 12, 2026 at 6:11 PM Wei Chuang <[email protected]> wrote: > Here is the updated -01 with fixes for the numbering and reference > to Section 4.3. > > https://datatracker.ietf.org/doc/draft-chuang-dkim2-sender-policy/01/ > > This document updates DMARC RFC9989 for DKIM2. In particular DKIM2 > verification supports MTA relay forwarding with message modifications > through multiple MTAs, so this updates DMARC to support those scenarios as > well. While DMARC defines a RFC5322 From alignment constraint with an > enforcement policy if validation fails, this generalizes and separates > enforcement policy from constraint validation policies. This provides a > mechanism for MTAs to declare support for DKIM2 through the DMARC DNS > policy record that helps secure DKIM2 from downgrade attacks. > > -Wei > > On Sat, Sep 12, 2026 at 7:57 AM Wei Chuang <[email protected]> wrote: > >> Hi Pietro, >> >> On Fri, Sep 11, 2026 at 2:30 AM MCN-IETF <[email protected]> >> wrote: >> >>> Hi Wei, >>> >>> I have a question about the per-message constraint policies, in >>> particular about who is authoritative for setting them when a DKIM2 chain >>> is restarted. >>> >>> My understanding of the proposal is that flags such as donotmodify and >>> donotexplode become sender constraint/validation policies carried by the >>> individual message, while the DMARC DNS record provides the external >>> enforcement policy. DKIM2 - DMARC Sender Policy Proposal.txtTXT >>> >>> If so, I would expect the Originator to be authoritative for those >>> constraints. >>> >> >> Indeed, that's the proposal in the Section named "DMARC Domain Owner >> Policy". >> >> >>> But I am not sure how this could work after re-origination or a chain >>> restart. >>> >>> >>> >>> For example: >>> >>> A (i=1, donotmodify) >>> >>> | >>> >>> B (i=2) >>> >>> | >>> >>> C removes the previous DKIM2 chain >>> >>> | >>> >>> C (new i=1, no donotmodify) >>> >>> | >>> >>> D >>> >>> | >>> >>> Receiver >>> >>> >>> >>> We discussed previously that, once C removes the previous chain and >>> starts a new one, the receiver has no protocol-level way to determine that >>> an earlier DKIM2 chain existed. >>> >> >> Agreed. >> >> >>> In this example, the receiver has therefore also lost the per-message >>> constraint originally expressed by A. More generally, how can the receiver >>> determine whether the current i=1 signer is the actual Originator that is >>> authoritative for the per-message policy, or a re-originator after an >>> earlier chain was discarded? >>> >> >> Correct, but I think this is working as intended. It might be easier if >> we include headers. >> >> Let's start with the headers sent by B. >> >> From: [email protected] >> DKIM2-Signature: i=1; d=A.example; [email protected]; [email protected]; >> f=donotmodify >> DKIM2-Signature: i=2; d=B.example; [email protected]; [email protected] >> >> Let's assume that A has a DMARC policy of: >> >> _dmarc.A.example >> >> v=DMARC1; p=reject >> >> >> C strips the headers and restarts the chain, keeping the original From >> header field, which is now misaligned. Here are the headers after C. >> >> From: [email protected] >> DKIM2-Signature: i=1; d=C.example; [email protected]; [email protected] >> >> Using the Author Domain from the RFC5322 From header field, Mail Receiver >> D looks up the policy at _dmarc.A.example which has p=reject. The message >> is unaligned with Author domain of A.example and DKIM2 signature i=1 >> d=D.example, and looks up the enforcement policy to reject. i=1 comes from >> the "DMARC Domain Owner Policy" section in the I-D. >> >> C could change the From as well, but then the message's identity >> changes. It's as if C created arbitrary content that resembles what A and >> B generated. >> >> >>> The inverse case seems relevant too: if C starts a new chain and sets >>> donotmodify, what gives C the authority to establish that constraint on >>> behalf of the domain still appearing in RFC5322.From? >>> >> >> The RFC5322 From always defines the Author Domain used for policy >> lookup. In the example they don't align, and the message will be >> rejected. >> >> >>> In other words, a DKIM2 signature can authenticate that C declared a >>> constraint, but does it establish that C is authorized to define that >>> constraint for the sender identity represented by the message? >>> >>> Is the intention that alignment and the external DMARC policy provide >>> that authorization, or is some additional mechanism needed to distinguish >>> an original i=1 from an i=1 created by re-origination? >>> >> >> Like DKIM, DKIM2 depends on the alignment check to prevent this sort of >> spoofing. >> -Wei >> >> >>> >>> Best, >>> Pietro >>> >>> >>> >>> >>> >>> *Da:* Wei Chuang <[email protected]> >>> *Inviato:* giovedì 10 settembre 2026 20:57 >>> *A:* Al Iverson <[email protected]> >>> *Cc:* Emanuel Schorsch <[email protected]>; [email protected] >>> *Oggetto:* [Ietf-dkim] Re: DKIM2 / DMARC Sender Policy Proposal >>> >>> >>> >>> Hi all, >>> >>> I've created an Internet-Draft form of this proposal: >>> >>> >>> >>> DKIM2 Sender Policy >>> >>> draft-chuang-dkim2-sender-policy-00 >>> >>> >>> >>> Abstract >>> This document updates DMARC RFC9989 for DKIM2. In particular DKIM2 >>> verification supports MTA relay forwarding with message modifications >>> through multiple MTAs, so this updates DMARC to support those scenarios as >>> well. While DMARC defines a RFC5322 From alignment constraint with an >>> enforcement policy if validation fails, this generalizes and separates >>> enforcement policy from constraint validation policies. This provides a >>> mechanism for MTAs to declare support for DKIM2 through the DMARC DNS >>> policy record that helps secure DKIM2 from downgrade attacks. >>> >>> >>> >>> https://datatracker.ietf.org/doc/draft-chuang-dkim2-sender-policy/ >>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chuang-dkim2-sender-policy%2F&e=b336b1a5&h=fc9bfd57&f=n&p=y&m=4hgn3X6XF5zH0GD> >>> >>> >>> >>> Please provide feedback. >>> >>> Thanks, >>> >>> -Wei >>> >>> >>> >>> On Wed, Sep 2, 2026 at 1:40 PM Al Iverson <[email protected]> >>> wrote: >>> >>> +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 >>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fxnnd.com%2Fcal&e=b336b1a5&h=a6f88194&f=n&p=y&m=4hgn3X6XF5zH0GD> >>> >>> >>> -- >>> Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato >>> non infetto. >>> Clicca qui per segnalarlo come spam. >>> <https://mail2.mcnsrl.it/action/4hgn3X6XF5zH0GD/report-as-bad> >>> >>> >>> Clicca qui per metterlo in blocklist >>> <https://mail2.mcnsrl.it/action/4hgn3X6XF5zH0GD/blocklist> >>> >> -- 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]
