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. > Since it's coming from you, one of the -bis authors, I'll take it as gospel that these are the actual DMARC's goals. I'll point out your 1. is the closest to what I mentioned earlier about origination but this is restricted to an authenticated From header field identity, and lacks any description around forwarding. But it is important to establish forwarding as a problem to get at the crux of the argument with DMARC and DKIM2. You do note that DKIM2 is an attempt to fix what is wrong with DMARC authentication. My understanding of those DMARC failures is that modified forwarded email typically breaks both DKIM and SPF. I would posit that DKIM2, the new kid on the block, potentially may solve that. But to make my case that there is a need for DMARC with DKIM2, let's dig into what DKIM2 does based on the -01 version https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/01/, with the caveat that just my interpretation even if I'm one of the spec's authors. Under Section 8. "Signer Actions" is Section 8.2 "Provide a "Chain of Custody" for the Message" which calls for "a valid "chain of custody" MUST be apparent when all of the DKIM2-Signature header fields are considered." This is implemented in Section 8.3 where "checking that the MAIL FROM value recorded in every DKIM2-Signature header field (except of course the i=1 instance) can be matched with a RCPT TO value of the next lower numbered DKIM2-Signature header field". It also calls for "signing domain (specified in the d= tag) and the MAIL FROM domain". So far so good. I would argue this does validate a forwarding path. Under Section 10. Verifier Actions and specifically Section "10.4. Check the Chain-of-Custody", it calls for checking " exact match between the MAIL FROM and RCPT TO parameters used when delivering a message and the values found in the mf= and rt= tags of the highest numbered DKIM2-Signature". It also validates "relaxed domain match ... between the signing domain of the most recently applied DKIM2-Signature header field and the mf=" That validates the most recent signature. But what about the prior signatures if they are not checked? It's easy to imagine potential mischief if the prior signatures are not checked. Some forwarder, malicious or gullible, may have signed for a forwarded message that doesn't have a valid signature. Such a message makes it easy to hide abuse that spoofs some victim's identity e.g. conceptually: DKIM2-Signature: i=2; d=verifiable.example; mf=; rt=; s=::valid.signature DKIM2-Signature: i=1; d=invalid.example; mf=; rt=; s=::invalid.signature From: [email protected] Is this authenticated? I would argue, yes, it is! When the receiver sees abusive content, it enables us to say the forwarder verifiable.example signed for the message containing abuse. However, does the DKIM2 signatures identify the From identity? I would argue, no, it does not, because we did not validate that the signature of invalid.example was correct. Hence, despite From header field alignment with the first signature, we should not use the From address identity to mean anything useful. The problem here is similar to when we say DKIM or SPF is authenticated but lacks RFC7489 From alignment. Instead we need to validate that first signature, establish that From header field relationship for DKIM2 i=1 signature, and follow the Chain of Custody to i=2. This approach is analogous to saying that there is an originator identified by the From header field, who chose to send a message. That message was then forwarded from i=1 to i=2 and onwards. This is useful information to a receiver, and why I think we need to distinguish DKIM2 authentication from DMARC with DKIM2 authentication. 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. > Regarding DKIM2 taking away responsibility from DMARC enforcement policy, I agree there is overlap, that could cause confusion, but I would point out that there are some properties that distinguish them. One such differentiating factor is DMARC's policy mechanism is more of a means to communicate the desired enforcement severity by the sender to the receiver for the From header alignment. That is different from DKIM2's flag for whether modifications to the message are permitted. I would propose that further untangling this, and finding a logical division of labor between DNS policies and DKIM2 signatures would be helpful. Keep in mind that sometimes the DKIM2 signer and the DNS owners are different entities. As to the bulk sender policy eliminating the need for DMARC, I would just point out that various bulk sender policies explicitly call for DMARC or implicitly by requiring alignment (e.g. Gmail <https://support.google.com/a/answer/81126?hl=en>, Yahoo <https://senders.yahooinc.com/best-practices/>, Outlook <https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730>). The view point I've heard around bulk sender policies was that it was meant to bring out authentication based on the IETF standards to help fight abuse. So I don't think those policies have eliminated the need for DMARC. If anything, I think it calls for evolving DMARC to meet the new authentication challenges. -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
