On Thu, 13 Aug 2026, Hannah Stern wrote: If they're in different transactions, the "lowest" in-transaction layer of a DKIM2 verifier can't spot the issue, only if the server then keeps a database.
The detection problem you and Bron describe is real. There is a related definitional problem that comes before it. Before receivers can build detection logic, they need a definition of what counts as a violation versus legitimate intermediary behavior. One category the BCP does not define: re-originating services. These include alias services, privacy-preserving mailing lists, and similar intermediaries that receive a message addressed to a relay identity, terminate it, and originate new outbound messages to the intended recipients. Whether the re-originator's outbound delivery counts as a donotexplode violation - or as authorized redistribution to the audience the sender chose to address - is a policy call the BCP has not made. And in either case, because the re-originator terminates the inbound chain, the original sender's flags do not propagate to the final receivers. >From the final receiver's perspective: a valid single-hop DKIM2 signature with >no prior chain, no original donotexplode flag visible. The receiver's >detection logic has no framework for evaluating this against the original >sender's intent - not because the re-originator did anything wrong, but >because the BCP does not define the category. As receivers build the kind of cross-transaction databases you describe, they will need a policy for these messages. Without BCP guidance, each deployment decides independently. The safe default is to treat an absent chain as suspicious, which is wrong for this class of service. R. Latimer noted on-list that this is part of a broader pattern: DKIM2 has deferred several hard deployment cases to BCP guidance that may not arrive in time. The re-originator definition is one concrete instance. Proposed text for this gap is at GitHub Issue #2 on dkim2wg/spec, filed June 2026 with no WG response to date: https://github.com/dkim2wg/spec/issues/2 The proposed Section 5 text defines re-originating intermediaries; the proposed Section 6.1 text gives receivers a basis for evaluating single-hop messages from these services rather than leaving it to per-site heuristics. I operate EMail Parrot, a privacy relay in this category. William Weiner Weiner Advanced Development LLC / EMail Parrot (emparrot.com) From: Hannah Stern <[email protected]> To: <[email protected]> Date: Thu, 13 Aug 2026 05:25:59 -0600 Subject: [Ietf-dkim] Re: How to check for "donotexplode" and "donotmodify" violations? > Hi, John! > > [No need to CC me, I'm on the list] > > On 8/12/26 19:09, John Levine wrote: > It appears that Hannah Stern <[email protected]> said: > > The draft says: > > If a verifier receives a message with a donotexplode request and > a later hop has indicated that it has exploded the message then > the message SHOULD be rejected. > > So according to how I'd plainly read it, the verifier would only check > if any subsequent hop has the "exploded" flag. > > However, what if a hop explodes the message without setting the flag? > > I think donotexpode is advice to cooperative signers since as you note, > there's no way for subsequent signers to check. I'd think that if a > mailing list implements DKIM2, it would reject or at least hold for a > moderator anything with donotexplode. > > Yeah. So a verifier should, as the spec, just check the exploded > flag in subsequent hops, catching half compliant hops (complying > with declaring exploded, but not compliant with the requirement to > not explode donotexplode mails). > > With the general approach in other areas of DKIM2 (make things > verifyable through the chain), I'm a bit suprised that here we > might specify something that's harder to impossible for a verifier > to check (only with a database about multiple copies one receives, > best with inter-site cooperation like sites exchanging data about > how often a site received which DKIM2-Signature line (e.g. > hashed)). > > For "donotmodify" it's specified that header fields may be added still. > If the recipes were optimal, that would mean that there are only "c" > entries. However, if a site reorders existing fields, it would need to > use "d" at least somewhat (due to the monotonicity requirement on copy > rules), and of course if a site is extra simplistic it might use "d" > even when "c" would work. So in the end we'd possibly need to create a > set of fields in the new version, and for each header field in the old > version, check if it's in the new set? Or how would you implement that? > > That does seem ugly, doesn't it? On the other hand, I'd think that it > wouldn't be hard to keep the new headers or maybe a set of hashes, and > check them after the changes are undone. > Yeah. For now I implemented a check if, for each field key in the > older header (reconstructed through recipes), the field values are > an _ordered_ subset of the corresponding values in the newer > header (allowing for differences that don't affect > canonicalization). But possibly that's not correct and I'd need to > check for _unordered_ subset/sub-bag (not allowing the count of > occurrences of the _same_ field value to decrease). > > Perhaps the approach of comparing bags of (hashes of) > canonicalized field values could be better. > > IMO the draft is a little under-specified here, still. > > > > R's, > John > Hannah.-- > Hannah Stern > > Software Developer > Mail Transfer Development > > 1&1 Mail & Media Development & Technology GmbH | | | > Phone: +49 721 91374-4519 > E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net > www.web.de www.mail.com www.united-internet-media.de > > Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452 > > Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr. > Verena Patzelt > > > Member of United Internet > > Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen > enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese > E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und > vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten > ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt > auf welche Weise auch immer zu verwenden. > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient of this e-mail, you are hereby notified that > saving, distribution or use of the content of this e-mail in any way is > prohibited. If you have received this e-mail in error, please notify the > sender and delete the e-mail. > > _______________________________________________ > 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]
