Hi Bron, Apologies in advance if I'm missing something obvious here, I implemented DKIM2 only a few days ago and wasn’t following the list that closely before.
Reading through 12.1.1, I have to say I don't personally see a limitation in the DSN propagation algorithm as it's written. It worked out cleanly when I implemented it. In Stalwart I ended up with two DKIM2 signing paths: a general purpose one for normal mail, and a separate one for DSNs that just follows the 12.1.1 steps directly (single Message-Instance, single DKIM2-Signature, mf=<>, rebuild the returned part, drop the added signature). For deciding that a message is a DSN, I don't rely on any new marker. I detect it structurally: the top-level part has to be multipart/report with report-type=delivery-status, and then I look inside for the returned content, either a message/rfc822 part or a text/rfc822-headers part. That extracted part is also exactly what I use to authenticate inbound DSNs under 12.1.2, so the same logic serves both directions. Given that, I don't think a dedicated DKIM2-DSN header is needed. The existing headers already tell us it's a delivery report, and a stripped singleton header would mean special-casing it in every verifier and forwarder that would otherwise just treat a DSN as an ordinary DKIM2 message. If we ever want to be completely explicit rather than inferring from structure, I'd suggest a small addition instead, a 'dsn' flag in the f= tag. Best, Mauro > On 2 Jul 2026, at 03:04, Bron Gondwana > <[email protected]> wrote: > > As I'm trying to implement DKIM2 DSNs, I am struck by very many things. > > 1) they're only ever i=1; because the next hop has to remove the details and > create a new DSN. > > 2) they're only ever mf=<> > > 3) they aren't modifyable (only ever a single message-instance, with no > recipe) > 3a) and the signed Mesasge-Instance of the headers they include already > hashes its own headers and can be verified. > > 4) their rt= must match the mf= of the top hop in the message; so can be > unambigously derived. > > 5) their d= must match an rt= from the top hop of the message. this is > required still > > So we could really just create a very simple singleton header: > > DKIM2-DSN: d=example.com; [email protected]; h=<mival> s=sel:alg:digest > > > It doesn't have to have anything else. h= is the same value as the header > value on the signed top message-instance, and then the digest is calculated > over just this header with the digest left blank like usual. > > This makes it really clear that this is a DSN. It is only ever expected to > be received by Bounce addresses, which will generally be dedicated processor > addresses which never see anything else, so have different rules about what > to accept anyway. > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC > [email protected] > > > _______________________________________________ > 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]
