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.
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.
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?
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?
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?
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]<mailto:[email protected]>> wrote:
+1 Yes, this makes sense, IMHO
On Wed, Sep 2, 2026 at 9:00 AM Wei Chuang
<[email protected]<mailto:[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]<mailto:[email protected]>> wrote:
Sorry for the delay in responding.
On Wed, Aug 26, 2026 at 1:39 PM Emanuel Schorsch
<[email protected]<mailto:[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]<mailto:[email protected]>
DKIM2-Signature: i=1; d=originator.example;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
DKIM2-Signature: i=2; d=mailinglist.example; f=unaligned;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[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
<[email protected]<mailto:[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]<mailto:[email protected]>
DKIM-Signature: d=originator.example
DKIM2-Signature: i=1; d=forwarder.example; f=unaligned,reporting;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
#2 DKIM2 -> DKIM1 -> DKIM2
From: [email protected]<mailto:[email protected]>
DKIM2-Signature: i=1; d=originator.example;
[email protected]<mailto:[email protected]>; rt=
-Wei
_______________________________________________
Ietf-dkim mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
Ietf-dkim mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
--
Al Iverson | Industry Research and Community Engagement Lead
Email: [email protected]<mailto:[email protected]>
Phone: (312) 725-0130<tel:(312)%20725-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]
