Hello all, Following the recent discussions on DKIM2, DMARC sender policy, and the risks associated with message modifications, I have been reflecting on one aspect that I believe may deserve further consideration. Should the RFC5322.From domain owner have some authority over which modifications can be made while retaining its authenticated identity? DKIM2 introduces an important capability: intermediaries can document modifications through a cryptographically verifiable Chain of Custody. However, I believe there may be a distinction worth considering between verifying that a modification occurred and establishing that the owner of the original From domain authorized that modification. A Fully Verified DKIM2 Message can demonstrate that the chain is valid and identify the intermediaries responsible for changes. But a valid chain does not necessarily imply that those changes were acceptable to the original domain owner. As Emanuel Schorsch recently pointed out, even a harmless message from a trusted domain could be received by a malicious intermediary, modified to contain phishing content, and redistributed with a fully verifiable DKIM2 chain. The intermediary's signature establishes responsibility for the modification, but not necessarily authorization from the original sender. This raises a concern about the conditions under which DKIM2 authentication should contribute to a DMARC pass for the original From domain. One possible direction might be to consider a domain-level policy rather than relying exclusively on message-level flags such as donotmodify. For example, a domain owner might wish to establish that modifications are not implicitly authorized, while retaining the possibility of explicitly allowing certain transformations where appropriate. A DNS-published policy would have the advantage of being controlled by the domain owner, rather than depending on each sending application or service to include the appropriate restriction in every message. The recently introduced DKIM2 Domain Policy Record in draft-ietf-dkim-dkim2-dns-03 is interesting in this context. Although its current f=strict flag addresses a different issue, it demonstrates that domain-controlled restrictions can be expressed independently of individual messages. I am not suggesting that this record should necessarily be extended, nor that a particular policy syntax or set of modification categories should be adopted. There are clearly important complications. Mailing lists, forwarding services, security gateways, and other intermediaries may legitimately modify messages. A restrictive approach could interfere with these use cases, and distinguishing acceptable technical transformations from changes that alter the meaning of a message is far from straightforward. There is also a fundamental difference between allowing a receiving system to trust an intermediary and allowing that intermediary to preserve the original domain's authenticated identity after modifying its content. The former is a local trust decision. The latter may be interpreted as an assertion about the original domain owner's authorization. My concern is that these two concepts should not become equivalent simply because the Chain of Custody is fully verified. I am therefore wondering whether sender-domain authority over modification authorization is a useful principle to explore, independently of how it might eventually be implemented. It may turn out that the existing mechanisms already provide sufficient protection, or that the additional complexity and interoperability consequences outweigh the benefits.
Of course, I may be overlooking something important, including relevant use cases, exceptions, or implications that I have not considered. Kind Regards Pietro Da: Emanuel Schorsch <[email protected]> Inviato: martedì 3 novembre 2026 00:28 A: Wei Chuang <[email protected]> Cc: Richard Clayton <[email protected]>; [email protected] Oggetto: [Ietf-dkim] Re: DKIM2 / DMARC Sender Policy Proposal Thanks Wei! On Mon, Nov 2, 2026 at 2:38 PM Wei Chuang <[email protected]<mailto:[email protected]>> wrote: On Tue, Oct 27, 2026 at 12:58 PM Emanuel Schorsch <[email protected]<mailto:[email protected]>> wrote: In the benign case I agree. For a mailing list or a trusted forwarder you are of course correct. The whole issue here is that you don't know who are benign forwarders. In the malicious case, it is the opposite, the malicious forwarder's identity is the more relevant thing to show. What I try to argue is in the general case for general mailbox user traffic that might traverse mailing lists, this identity doesn't have to be rewritten for DKIM2. For more sensitive transactional traffic, e.g., PayPal/IRS/billing traffic that is NOT intended to go through mailing lists, it can be distinguished by a flag donotmodify. The mandates From rewriting behavior, or that MTAs reject such traffic. Either way with DKIM2, you know the forwarders' identities via signature rt=/mf= tags and from earlier versions of the From headers as they are rewritten. Isn't this what DMARC allows today? Less sensitive mail can stick to p=none. And the reverse direction is equally true, "Either way with DKIM2, you know the originators' identities". It still seems to me to come down to a question of defaults. And whether the default behavior should change from what it is today on day one of DKIM2 counting for DMARC. Or if we should revisit this discussion once we have seen how DKIM2 adoption is proceeding in the field and how providers are updating to handle it. To be clear, I fully agree that receivers can and should use their local understanding of their customers' relationships to undo the fromMunging and show the originator when that is more relevant. Where I disagree strongly is that the spec should default to showing the originator for a p=reject domain instead of requiring receivers to make an intentional and informed choice into adopting that behavior. What I'm suggesting has one additional change, in that it proposes publishing a "donotmodify" flag on the signature, to distinguish the traffic sensitivity. -Wei I have two concerns on the "donotmodify" flag. One, I'm not yet convinced of the benefit. It seems like it shifts the classification from the domain level "p=reject" to the message level. Do you anticipate IRS/Paypal/Google adopting that? Do you anticipate that they'll be comfortable with their domain defaulting to allowing modifications and relying on all their infra updating to adding "donotmodify" on every risky message? It seems more realistic that they would want the default to be "donotmodify" and allow tagging a message with "okaytomodify" to indicate that despite the domain level guidance, this specific message is low risk and okay to modify. That would also require fewer changes on day one. My second concern, and a bigger concern, is that the content of the message is irrelevant because arbitrary body modifications are allowed. The risk comes from the domain itself. Suppose someone from irs.gov<https://urlsand.esvalabs.com/?u=http%3A%2F%2Firs.gov&e=b336b1a5&h=ee0b2eeb&f=n&p=y&m=4jJSb15003zGxGs> participates in an IETF discussion and is sending a text only low risk message. They tag it with "okaytomodify". But now, the recipient has a validly signed irs.gov<https://urlsand.esvalabs.com/?u=http%3A%2F%2Firs.gov&e=b336b1a5&h=ee0b2eeb&f=n&p=y&m=4jJSb15003zGxGs> message and can change the body / subject in any way they want with recipes and now not modify the fromHeader. The issue is that even the lowest risk message from a phishing target domain has high risk because of body recipes. That's the main reason why I don't see much of a use-case for a message level "donotmodify" tag instead of the usual DMARC behavior. Best, Emanuel -- Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non infetto. Clicca qui per segnalarlo come spam.<https://mail2.mcnsrl.it/action/4jJSb15003zGxGs/report-as-bad> Clicca qui per metterlo in blocklist<https://mail2.mcnsrl.it/action/4jJSb15003zGxGs/blocklist>
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
