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]
