There's definitely an interoperability issue with Postfix's "bounce(8)" as currently built. It always produces Content-Transfer-Encoding: 8bit bounces, which then get downgraded on delivery to a non-8-bit next hop, which breaks the signature. Ouch.
Then again, it's already feeding into a milter in my current confit, and the milter can rewrite it. An alternative would be to replace "bounce" with a dkim2 aware version of bounce which would obviously also produce 7bit for maximum compatibility. I will write a separate email in a second, because I have other thoughts... Bron. On Mon, Jun 29, 2026, at 09:38, Vittorio wrote: > Hello Edmund, > > To clarify the two points you raised: > > On the embedded original message (MIME encapsulation): > The DKIM2 headers and modification indicators (MI) that Hop B added > before attempting delivery to Hop C are part of the DSN body, not live > message headers. They sit safely encapsulated inside a message/rfc822 or > text/rfc822-headers MIME part. The verifier of the DSN does not parse > them as DKIM2 headers, they are content, covered by the DSN's own bh=. > There is nothing to unroll. > > On Postfix and milter routing for DSNs: > This is an MTA integration detail, not a protocol limitation. > While Sendmail inherently routes internally generated bounces through > the milter pipeline, Postfix requires explicit configuration via > internal_mail_filter_classes = bounce. > The Postfix documentation warns that filtering internal bounces can be > unsafe, but that warning specifically targets content filters or milters > that might reject a bounce, triggering a dangerous mail loop. > This is where a clean architectural separation between the Signer and > the Verifier roles solves the deployment friction: > - A pure DKIM2 Signer does not perform policy checks, verification, or > content filtering. It only observes the outbound envelope and applies > the DKIM2 signature. > - The Signer never issues a REJECT or TEMPFAIL and running it under > Postfix's internal bounce class is completely safe and free of looping > risks. > > By decoupling the signing function from the validation state machine, > operators can safely use standard MTA milter slots for DSNs without > custom routing pipes or shell scripts. > > Regards, > Vittorio Moccia > > Il 2026-06-27 20:26 Edmund Lodewijks ha scritto: > > On 2026/06/27 01:53, Vittorio wrote: > >> Hello Edmund, > > > > Hello Vittorio, > > > > Thank you for replying! > > > >> My short answer: a DSN is a new message. ... > > Correct. > > > > This is probably where the confusion regarding my question comes in: My > > complications are with regards to the embedded original message within > > the DSN (and I agree that the DSN is a completely new message, which > > needs to somehow be DKIM2 signed itself). > >> its standard bounce logic. The DKIM2 signing milter signs it as any > >> other outbound message with the envelope values as presented by the > >> MTA. > > > > In Postfix, this appears not to be the case, as referred to in my > > previous email. > > > > Postfix will not run the DSN message through the milters, so no DKIM2 > > signing will happen. Unless you enable a specific option, which then > > routes the message through all kinds of things, and Postfix itself > > suggests that it is not really safe to do so. > > > >> There is no recipe to undo, no prior chain state to extract or embed > >> and no DKIM2-specific DSN generation path. > > > > This part applies not to the DSN (it is a new message, as you point > > out), but to the original message. Here we have a few issues: > > > > 1.) When our mail server received the message and sent the "250 OK" to > > the previous hop, it added a DKIM2 signature and MI to the original > > message, before it passed it on to the next hop. The next hop, however, > > refused to accept the message with a 5xx. > > > > The original message is often embedded in the DSN (for Postfix, see > > [0]), but now that original message has our DKIM2 sig + MI in its > > headers, which we might want to unroll. They are of no use to the > > original sender.. This is my question. > > > > 2.) Based on the size of the original message, Postfix will either > > embed the full original message, or only the headers [1]. This size can > > be set manually, and Postfix admins need to be (made) aware of this. > > > >> The milter does not need to know that the message is a bounce. > > > > This applies to the DSN again. > > > >> Regards > >> Vittorio Moccia > > > > Kind regards, > > Edmund Lodewijks > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- 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]
