On 10/08/2026 6:42 pm, Wei Chuang wrote:
On Sun, Aug 9, 2026 at 12:02 PM Emanuel Schorsch <[email protected]> wrote:I am concerned with the phishing implications of recipes. For example, forirs.gov <http://irs.gov> or paypal.org <http://paypal.org> the phishing potential seems quite high of being able to modify URLs, dollar amounts, sending instructions or other key information with recipes and still having a DMARC pass. I understand that the recipes allow uncovering who the malicious actor was. But detection algorithms will never be perfect and with the current UX that most mail providers use, any mail that slipped past those detection algorithms using recipes would be an extremely convincing phishing attack. I would love to hear people's general thoughts on this topic and any potential solutions they have in mind. To start the conversation, two specific proposals I thought of that might help (though I'm open to alternative solutions):As you state, DKIM2 security property depends on identifying the contribution of message content by actors on the message. A pass indicates that all changes are identifiable to some responsible signature signer, but it up to local policy to determine what to do with that information. I agree that changes to URLs and dollar amounts are more suspicious, and I think you would agree that adding purely text headers/footers (i.e. no URLs) and Subject header fields are generally less worrisome. While I agree that some guidance is a good idea, I think specifying acceptable changes at the protocol level would be unwise because we cannot describe safe or unsafe changes. These are probably things for the BCP at the IETF or M3AAWG, or for per-receiver guidance as those can more readily be updated. For example, it may be a good idea to provide a canonical recipe template for a mailing-list header/footer in the BCP. Likely these are less risky changes.
I have restored Emanuel's second paragraph above your response, because that's the real question. It's not how does it work, it's how does this affect e-mail in general, which is a much deeper question and one that has been largely overlooked by the Working Group. This is a systemic failure that can be traced back to claims made even before this Working Group was re-opened.
I don't think anyone who has objected to this change or raised concerns about it has done so through a lack of understanding of _how_ it works. Their concerns surround the change in behaviour and the move from pure cryptographic verification of the intent of the signing domain to reliance on heuristics. This as a significant regression.
Your co-authors have been very clear about DKIM2 being more closely aligned with ARC, indicating the DKIM name is being used because it is branding people have heard of it. They have also highlighted this being a change big providers want.
Claims made that the supposed benefits of DKIM2 would be "free" with a software upgrade have since been replaced with an acknowledgement that a filter-based implementation would be fragile and highly dependent on a compliant configuration, while claims that no core modifications are necessary to SMTP have been adjusted to an expectation of DKIM2 functionality being implemented in MTAs.
RFC 5321 (and earlier) requires that "Each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs" and further states that "In many cases, the cost of extending the SMTP service will likely outweigh the benefit". Those are the requirements for ESMTP extensions. Changes to the underlying protocol, which this is, must therefore be subject to at least the same level of scrutiny, if not more.
Despite this, we still have little more than a motivating document stating several "nice to have" features. This is not justification for what amounts to a significant change in both SMTP behaviour and established DKIM functionality. As a representative of one of the large providers that are said to want this change, and the co-author of the specification, it's disappointing to see further statements that essentially amount to "We will build it because we want it and someone else at a later date can give guidance to make this work in some capacity".
Regards, R. Latimer
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
