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 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. -Wei > > On Thu, Apr 30, 2026 at 7:29 AM Todd Herr <todd= > [email protected]> wrote: > >> >> >> On Wed, Apr 29, 2026 at 2:13 AM Wei Chuang <weihaw= >> [email protected]> wrote: >> >>> I've been meaning to reply about this exploration of safety with DKIM2 >>> and implicitly DMARC as BIMI is based on DMARC. >>> >>> The point I meant to make was, in the past, we've assumed that DKIM and >>> DMARC authentication pass doesn't mean the message is safe. For example, >>> spammer are pretty adept at authenticating their emails. I would say the >>> same thing applies to DKIM2: just because a message passes doesn't mean >>> it's trustworthy. As others mentioned later in the thread, DKIM2 provides >>> a provable technique to show, for example that the content in the footer >>> came from a forwarder, while the content in the body came from the >>> originator. 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. >>> >>> There is another question. How does DKIM2 interact with DMARC? We >>> could take a narrow view that only DKIM RFC6376 applies to DMARC RFC7489 or >>> DMARCbis. Presumably it means that the From header must align with the >>> DKIM2 d= domain at the most recent (largest i=n) with a passing signature >>> validation. However this precludes making any changes at the forwarder, >>> and I would argue that's too limiting. At the risk of rocking the >>> carefully crafted understanding of DMARC's purpose, it is to encourage >>> authentication and provide a means for the sender to communicate the >>> sender's email address to the receiver through the alignment process. I >>> think DKIM2 can both authenticate and propagate the originating sender's >>> email address via the original From header, as well as any other message >>> that rewrites the From header. In this expansive view of DMARC with DKIM2, >>> if the From header aligns with the DKIM2-Signature d= domain at i=1, it >>> potentially may be DMARC aligned. Then we have to check that all >>> successive DKIM2-Signatures are valid and that the mf= and rt= match >>> between successive instances match. That might be: >>> >>> - DKIM2 signature validate after message algebra for all signatures >>> i=1..n >>> - For i=1..n there exists a well defined forwarding path >>> - mf= at i=m is aligned with DKIM2 signature d= >>> - rt= at i=m, it is aligned with i=m+1 DKIM2 signature d= >>> - Original From header was aligned at i=1 with DKIM2 signature d= >>> domain >>> - From header may be rewritten, but must be recoverable via >>> header algebra >>> >>> If all these are true, then it would be a DMARC pass in this expansive >>> view. >>> >>> This is just a strawman for further discussion at the interim meeting >>> later today. >>> >> >> In the interests of capturing (and expanding on) what I said during the >> interim on electronic paper, here is why I'm pessimistic about a future for >> DMARC in a world where DKIM2 achieves universal deployment... >> >> DMARC does three things for domain owners: >> 1. It allows the domain owner to announce, through a DNS TXT record, that >> it has taken (or is taking) steps to ensure that mail using its domain in >> the RFC5322.From header is authenticated as DMARC defines "authenticated" >> 2. It allows the domain owner to request message handling disposition for >> messages using its domain that fail DMARC validation >> 3. It provides a mechanism for the domain owner or its designee(s) to >> receive reports about DMARC authentication statistics for messages using >> its domain, with those reports providing some clues that can be useful in >> sussing out authentication shortcomings and possible misuse of the domain. >> >> While a message receiving site is free today to impose a policy of "no >> DMARC pass means rejection, regardless of domain owner preference," doing >> so risks rejecting some wanted mail due to the acknowledged shortcomings in >> SPF, DKIM, and DMARC, shortcomings that DKIM2 has a goal of addressing, >> yes? >> >> I will note here that since DKIM2's goal includes, in my words, fixing >> what's broken with DMARC, it does not make sense to me to have DKIM2 as an >> authentication mechanism that underpins DMARC; rather, DKIM2 should stand >> alone in my opinion. >> >> Fast-forward to an ecosystem where DKIM2 is universally deployed (for >> some value of "universally"), and I believe we will be living in an >> ecosystem where receivers will impose a policy of "no DKIM2 pass, no >> entry." They will be safe to do so, because if DKIM2 achieves its goal of >> fixing the shortcomings in authentication that exist in indirect mail >> flows, then a message that fails DKIM2 will be correctly deemed to not meet >> the standards for accountability that DKIM2 has imposed; I know if I were >> still in a position where I was focused on inbound email traffic to a large >> mailbox provider, I would stridently argue for putting such a policy in >> place at that time. Further to this point, I am not saying that the policy >> will be "a DKIM2 pass means the message is accepted"; rather, the policy >> would be "a DKIM2 pass is required as one of several criteria that a >> message must meet in order to be accepted." >> >> Now, if you're going to argue with me here that there may be legitimate >> reasons for accepting a message that fails DKIM2 because of corner cases or >> edge cases or this reason or that reason, then I would counter that DKIM2 >> will not have achieved its goal of addressing existing shortcomings in the >> authentication landscape, or worse, it just introduced new ones in that >> scenario. >> >> So, indulge me and envision a world where DKIM2 is universally deployed, >> issues with authentication and indirect mail flows have been consigned to >> the dustbin of history, and mailbox providers now require DKIM2 to pass in >> order for acceptance of the message to be a possibility; at that point, >> whither DMARC? >> >> 1. In my opinion, there's no need for a DMARC DNS record to announce that >> a domain has taken (or is taking) steps to authenticate with DKIM2; it's >> now a requirement. >> 2. In my opinion, there's certainly no need for a domain owner to request >> message handling disposition for messages that fail DKIM2; that decision is >> made for you by the mailbox providers' "no DKIM2, no entry" policy. >> 3. There *might* be a use case for DMARC reports, but given that as I >> understand DKIM2, it's designed to route bounces back to their origination >> point, notice of DKIM2 failures in the form of bounces will make it back to >> the domain owner (or its designated sender of "legit" mail) much more >> quickly than would DMARC reports. As for messages that were not >> authorized by the domain owner, I know there are some who believe DMARC >> reports to be valuable in identifying takedown candidates and such, but I >> do not share that belief, and I further posit that such forgeries may be >> greatly reduced if the bad guys know that messages that fail DKIM2 will be >> rejected out of hand. >> >> I admit that this is all speculative on my part, and it'll take years to >> prove me right or wrong, but this is where my head's at today regarding >> DKIM2 and DMARC. >> >> -- >> Todd >> >> _______________________________________________ >> 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] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
