On Wed, Sep 16, 2026 at 2:27 PM Emanuel Schorsch <[email protected]> wrote:
> Thanks Wei the proposal to add the auth= tag looks great! > > Some questions on the other aspects: > > - Is the suggested consequence for a violation of the donotmodify flag > (or other flags) "domain > owner's enforcement policy"? So if the message was modified despite > the senders instructions and the domain owner has p=reject then the > suggested action would be to reject? > > That's right: it should use the domain owner's enforcement policy, reject, based on the policy found at the authenticated identifier. > > - If there is no donotmodify flag and the body is modified and the > fromHeader isn't munged then is it considered a Dmarc pass? > > Correct, it is a DMARC pass assuming authentication pass and alignment. > > - Why do we need to switch from evaluating the current RFC5322 > fromHeader to evaluating the domain at i=1? Is it to deal with the > consequences of the second bullet? It seems to imply if you want to violate > the originators intent, instead of just needing to do fromHeader munging > (how it works today to take ownership and bypass), you would need to start > the chain over (unnecessarily throwing out useful information). > > If From header munging occurs, it typically supports DMARC with DKIM1, not DKIM2, which can authenticate through message modifications at forwarders. The munged From header's authenticated domain represents the forwarder's policy. That forwarder isn't the author who introduced the message; rather, it works in support of the author to deliver the message to its final destination. The author would more commonly be viewed as the message owner. More concretely, a user sends a message to a mailing-list. Should we use the policy of the mailing-list or the message author? I prefer using the author's policy. If the answer to the second question is yes. Then I think we should change > that to keep consistency with the existing DKIM/DMARC world, and only > consider it a DMARC pass if the current fromHeader aligns with a domain > that has signed the current version of the text (aka ignoring recipes). > The language currently says the authentication identifier comes from the >From header either at the highest i=n or i=1. > This would keep consistency in the following examples: > > 1) Mail is sent to a DKIM2 mailing list which adds a footer. FromMunging > is done. fromHeader now aligns with a signer of the current copy. DMARC > Pass. Same as today. > 2) Mail is sent to a DKIM2 mailing list which adds a footer. No > fromMunging is done. fromHeader does NOT align with a signer of the current > content, but does align with the original sender pre-change-recipe. DMARC > Fail. > I think the goal of DKIM2 with an updated DMARC is to support keeping the original aligned From header and allow that to count as a pass. > 2a) If fromDomain is p=reject then mail would be rejected. Same as today. > (with your proposal, mail would be accepted, which would be a big change). > 2b) fromDomain is p=none then mail is accepted. Same as today. > > If I'm understanding right, because of this consistency most mailing lists > would continue to interoperate just as well as they do today. E.g. IETF > which does fromMunging if there was p=reject would continue to be > unaffected by 2a and 2b would continue to work for IETF as it does today. > Current behavior involves From header munging caused by the existing DMARC and DKIM; DKIM2 and updated DMARC must initially support and handle this. However, this doesn't mean we must continue supporting From header munging in the distant future once DKIM2 and updated DMARC adoption is widespread. -Wei > > Best, > Emanuel > > On Mon, Sep 14, 2026 at 1:16 PM Al Iverson <al.iverson= > [email protected]> wrote: > >> 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 <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] >> >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
