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> >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
