On Sat, Oct 24, 2026 at 7:49 PM Wei Chuang <[email protected]> wrote:
> On Fri, Oct 23, 2026 at 10:56 AM Emanuel Schorsch <[email protected]> > wrote: > >> Hi Wei, >> >> I'm still very concerned about the security and safety risks being >> introduced by allowing a DMARC pass for body changes even if they don't >> munge the From. I think it introduces serious phishing and spear phishing >> risks for sensitive domains that should not be the default spec behavior. A >> DKIM2 intermediary that legitimately received a message could replace the >> body with a phishing message, record a Recipe that restores the original, >> and deliver it with a DMARC pass for the author's domain. With donotmodify >> removed in -07, the domain owner has no way to prevent this. I think a >> DMARC pass should keep meaning what it means with DKIM today: the From >> domain signed the content as delivered. >> > > I think that position outlines the crux of the difference. While I > understand your perspective, I think that human recipients can better make > security decisions using the author's identity of the originating message > than the forwarder's identity. > 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. > If we don't require From header munging, we lose the display name part of > the RFC5322 From header but since that's not authenticated, I don't think > we're losing anything. If the forwarder is malicious and introduces > phishing or malware, keep in mind that the originator who sent the message > through that malicious forwarder shares some responsibility for that > malicious traffic. > This is definitely not true at a small scale. This exact conversation came up with DKIM replay, Gmail/IRS/Google/Paypal sending out one message to a user that requests it is unavoidable behavior. If the spec allows that user to replay that message 1million times then it is the spec's failing. If they allow the user to request 1 million messages then it is a different story. In the exact same way if the Spec allows any recipient to modify the message and insert any malicious content they want while not changing the fromHeader then that is the specs failure. Spear phishing is real. Phishing campaigns targeting high value individuals are real. You are significantly increasing the risk and effectiveness of phishing campaigns with this change. You will never have 100% accuracy identifying what "content" is malicious. Reputation is always reactive and takes time to catch up. That is effective for spam, but much less so for phishing. You are introducing a gaping hole for phishing which is a footgun which should not be the default behavior for the spec. 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. > The other reason the draft-chuang-dkim2-sender-policy > <https://datatracker.ietf.org/doc/draft-chuang-dkim2-sender-policy/> > draft chooses an i=1 originator domain DMARC policy is that DMARC reports > should go there. The author sent the message down that path and if the > message has a delivery issue due to authentication, presumably they should > be able to find out via reports. The originator should control the > enforcement action if any to prevent spoofing of their domain as well as > any other domain level policy. > I don't have any concerns about the DMARC reports proposal. Some suggested language to preserve that: "When the domain of the RFC5322 From header field recovered at i=1 differs from the Author Domain, Mail Receivers SHOULD also send DMARC reports for the message to that domain's owner, identifying the Signing Domain of each DKIM2-Signature that modified the message. This does not apply where a later DKIM2-Signature has the "feedhere" flag; reports are then sent to that Signer instead." Best, Emanuel
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
