Sorry I should clarify the steps of my reasoning which were spread out in the earlier description. When a receiver sees a "donotmodify" message that has been modified, the receiver SHOULD apply enforcement. I propose looking up the signer's DMARC policy. However if a local policy mandates forwarding, I propose the forwarder MUST delete all prior DKIM2 headers. Then it re-signs the DKIM2 signature as itself to take ownership of the chain of custody. I have heard this may happen if a forwarder has a contractual obligation to the receiver to always send the email even if it appears maliciously modified. The receiver MUST not forward the message. Despite that, if the message is forwarded (because this does unfortunately happen) by the receiver, the re-signed DKIM2 message will not authenticate as the originator because those headers have been deleted. The downside of removing headers is that it removes forensic evidence for subsequent receivers.
Vittorio this has elements of your approach. I would be happy to hear of other improvements too. -Wei On Sat, May 16, 2026 at 5:27 PM Vittorio <[email protected]> wrote: > Hello Wei, > > the proposal that MTAs forwarding null-recipe or "donotmodify" messages > should delete all prior DKIM2 headers and re-sign as themselves is > operationally equivalent to breaking the chain of custody, which is the > core property DKIM2 provides independently of body recipes. > If a node deletes the chain and re-signs as itself, the receiver sees a > single-hop message with no history. The originator's identity, the > forwarding path, and the envelope binding at each hop will all be gone. > For a "donotmodify" message from a high-security domain like irs.gov, > this means the receiver can no longer verify that the message originated > from irs.gov at all. The flag designed to protect the message's > integrity would result in the destruction of its provenance. > The alternative is simpler: a node that cannot comply with "donotmodify" > should reject the message. This preserves the sender's intent without > destroying the chain for downstream verifiers. > > It is also worth noting that chain of custody verification does not > require trust in intermediaries. Each hop verifies the previous > signature cryptographically before signing its own, so the chain is > validated in real time during transit, not reconstructed after the fact > by the receiver. This is a property of the signature chain itself, not > of body recipes or message algebra. > > Regards, > Vittorio Moccia > > > Il 2026-05-16 23:03 Wei Chuang ha scritto: > > On Thu, Apr 30, 2026 at 11:16 AM Emanuel Schorsch > > <[email protected]> wrote: > > > >> Thanks Todd and Wei for some interesting thoughts! > >> > >> To start with some clarifications and terms. > >> > >> RFC5322.From: > >> As far as I can see DKIM2 says nothing about the RFC5322.From which > >> seems like an omission if the intention is to replace DMARC. Todd, > >> where do you envision the guidance and policies around RFC5322.From > >> sitting in the long term future? > > > > +1. There also needs to be clarity potentially around which > > RFC5322.From as it may be rewritten. DKIM2 enables those header fields > > to be recovered. My assumption is that recovering and verifying > > alignment with originating RFC5322.From at the DKIM2 i=1 would be > > preferred, but welcome clarification. > > > >> DKIM1 vs DKIM2 pass semantics: > >> DKIM1 pass has clear semantics for a pass, the message content is > >> unmodified from the original message. This is more ambiguous in the > >> DKIM2 world. It can mean: > >> 1) Content is unmodified. Chain of custody is just added. > >> 2) Content has reversible modifications that are recorded and can be > >> verified. > >> 3) Null recipe. Equivalent to an ARC pass today where all you can > >> verify is the most recent hop and the rest is that hop's assertion. > >> > >> I think it is important that these are clearly recorded as different > >> and that we have consistent terms to refer to them. The idea that 2 > >> and 3 are equally a pass as 1 is makes me hesitant and concerned. > >> I'm bad at naming but for the sake of this email I'll call them > >> PASS, MODIFIED_PASS, NULL_PASS. > >> > >> So for the sake of this discussion let's consider a high risk domain > >> like irs.gov [1] that currently has a p=reject policy. I am > >> interested in how things will be handled if there are modifications > >> and the visible fromHeader is unchanged. This is very relevant to > >> the question of whether mailingLists will continue rewriting > >> fromHeaders and what kind of phishing vectors we are opening up. > >> > >> 1) NULL_PASS. This seems equivalent to a local policy override of > >> the DMARC p=reject policy and should be treated as such. I would be > >> extremely wary of such behavior because of the high risk and it > >> seems appropriate only for sophisticated users, e.g. > >> enterprise/consumer users that can configure policies validating > >> that they explicitly trust that forwarder/gateway. > >> > >> 2) MODIFIED_PASS. This still seems to me equivalent to a local > >> policy override of the DMARC p=reject policy. The risk is simply too > >> high in terms of what sophisticated attackers can insert into an > >> email under someone else's identity. Even with the reversible > >> modifications I think this is simply too high risk and should by > >> default be spam-foldered at the very least. Attackers are endlessly > >> creative and the spec as it stands has no content restrictions on > >> what kind of modifications may be included. > >> > >> Wei, you say: "Safety comes from analyzing the content to find the > >> phishing link appended to the IRS email's footer, and then taking > >> action to protect the user. However, safety also involves ensuring > >> the IRS is not negatively impacted which DKIM2 helps prevent." > >> > >> But I think there is a third layer here, safety includes conveying > >> accurate information to users. I want to over-simplify and just > >> consider modifications which are additions so I can make the analogy > >> to the physical letter. If you have a signed and physically sealed > >> letter there is nothing stopping you from adding a note sticking > >> both in a new envelope and forwarding it along to the final > >> recipient. It is then clear to them what is the note you added and > >> what is the original sealed envelope. It should be equally clear to > >> the digital recipient today what is the modification and what is the > >> original letter. And I think we should be extremely wary of anything > >> which hides that distinction under the assumption that our security > >> systems will have 100% accuracy. > >> > >> This seems to me a non-trivial UX problem. Some sample approaches of > >> what to display to the final reader: > >> 1) Here is the original email and the original fromHeader. Can be > >> validated through the full chain of custody. Low risk of > >> communicating incorrect information. > >> 2) Here is the final email with the final fromHeader. Can be > >> validated. Low risk of communicating incorrect information. > >> 3) A UX which shows which content was original and which is new and > >> which is attributed to which author. This seems to require a change > >> from how email is usually displayed to avoid requiring the user to > >> pay very close attention. > >> 4) Showing the final email with the original fromHeader. Can easily > >> give the user an inaccurate picture of who generated the viewed > >> content. Is fully reliant on 100% accuracy of identifying malicious > >> content. Introduces a dangerous vector and should only be done if > >> the user has explicitly indicated they want that behavior. > >> > >> When we are discussing a possible IRS phishing email, if we view > >> safety as a series of layered protections then from a safety > >> perspective we have from strongest to weakest: > >> 1) rejecting the mail (user will never see it) > >>> 2) spam-foldering (user probably won't see it) > >>> 3) inboxing with warnings (user might ignore warnings) > >>> 4) inboxing with user visible clues of tampering (attentive users > >> will notice and be suspicious) > >>> 5) inboxing with no user-visible clues of tampering > >> > >> I think it is important that DKIM2 is set up to enable receivers to > >> do a good job at all 4 layers. The majority of abuse fighting comes > >> in levels 1-3 but I think it is still extremely important to > >> preserve #4. > >> > >> I say all this to explain why my preferred vision of the future > >> world: > >> 1) DMARC p=reject remains the gold standard and preferred policy for > >> everything except DKIM2 PASS (MODIFIED_PASS and NULL_PASS would not > >> meet the bar and would be a matter of local policy). BIMI would not > >> show logos or consider it passing unless there was a DKIM2 PASS. > >> 2) fromHeader rewriting when modifying the email remains standard > >> practice. Receivers experiment with UX and solutions to reverse that > >> fromHeader rewriting under safe conditions. > >> > >> I think the record of reversible content modifications is useful for > >> spam fighting and I expect will enable many more ways to safely do > >> #2. But I want to make sure we don't treat it as a DMARC pass by > >> default and presume that we understand all the security risks there > >> before people have experimented with using those body modifications > >> in production over time and we have seen what security issues > >> result. > >> > >> Best, > >> Emanuel > > > > So I do agree that the IRS is a good example of why relying on > > reputation systems alone to solve this is problematic, as it allows > > for the damage to be done. Solving this issue through the UI is also > > doubtful as UX research indicates problems with this approach. What > > could be done instead is that senders like the IRS with high security > > requirements could mark their messages with the DKIM2 flag > > "donotmodify" which says "this signer requests that the message not be > > modified from the form in which it is sent". One issue here is that > > the DKIM2 draft does not fully specify what is meant by not being > > modified. Is the prohibition only the body or does the headers also? > > If the latter, which header fields are protected? Would that be > > Subject, From, To, Cc, and other RFC5322 originator and destination > > fields? Receivers that see modified messages marked with the flag > > indicating "donotmodify" ought to lookup the DMARC policy of the > > signing domain, and apply the enforcement policy published there. > > > > I also agree that there needs to be more clarify around null recipes > > and their scoping. One thing that is said around "donotmodify" is > > that "A system that, by local policy, ignores this request MUST NOT > > allow the message to be forwarded on to any MTA outside its control." > > There should be similar language for systems that use null policies. > > > > > > I propose that the specification or BCP should say that MTAs that need > > to forward such null recipe, "donotmodify" or "donotexplode" messages > > onwards for whatever reasons, should delete all prior DKIM2 headers > > and re-sign the DKIM2 signature as themselves. This probably means > > that the above language needs to be tweaked for this. > > > [...] > > _______________________________________________ > 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]
