On Sun, Aug 9, 2026 at 12:02 PM Emanuel Schorsch <[email protected]> wrote:
> Hello all, > > I am concerned with the phishing implications of recipes. For example, for > irs.gov or 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. > 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 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): > > 1) Move the current paragraph in the BCP > <https://www.ietf.org/archive/id/draft-ietf-dkim-dkim2-bcp-00.html#section-5.7-1> > on "Continue doing From munging" to be a MUST under the body recipe section > of the spec <https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/>, > and require verifiers to also verify that the visible fromHeader matches > the envelope MAIL FROM when verifying a recent Body Recipe hop. Since this > risk is specifically caused by the body recipe section. The lack of > fromMunging from the IETF reminded me of the importance of moving this from > a suggestion to a required part of the verification step. Otherwise, the > IETF mailing list would go from taking ownership of messages and having a > clear DMARC fail to suddenly having a DMARC Pass for the original senders. > Rather than bringing in DMARC which applies sender policy, I'd rather have the From header field alignment indicate claimed authorship of the message > 2) For "11.1. Output States" distinguish PASS from PASS - RECIPE. To me, > the ability to achieve a pass while changing the content is concerning > enough that it needs to be a clearly distinguished PASS state. This doesn't > by itself change anything, different receivers can have different handling > of PASS - RECIPE. But it will make the semantics clear (e.g. in the Gmail > "Show Original" tab which shows the DKIM result) and allow DMARCbis/BIMI to > have more granular handling when they are updated to decide how to handle > DKIM2. > To me a DKIM2 pass indicates that all changes are identifiable to some responsible signature signer, which I think it does. That said, there could be other more stringent verification criteria that build upon a DKIM2 verification result, much like a "DMARC pass" builds upon DKIM1 and SPF results, that could be evaluated and reported. These might have the safety properties you're thinking of. -Wei > > Best, > Emanuel > _______________________________________________ > 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]
