[Ietf-dkim] Re: DKIM2 and DMARC (was Re: Re: New I-D: A Deployment Profile for DKIM2 via Milter Interface)

[Bron Gondwana <[e-mail]>]

Yeah, this sounds like a losing arms race of workarounds.

a) I don't want you to forward this
b) but I really REALLY want to forward it, so I'm gonna do it anyway
c)  ¯\_(ツ)_/¯ 

And then trying to come up with some policy work around to say "don't forward it unless you really REALLY have to", in which case it's suddenly OK.

Unless (c) trusts (b) to be allowed to do forwarding of any random stuff to it, this is going to cause pain.  We can't design around that with technological solutions, that's a real world trust relationship question.  And mostly, it's (c) that's going to have the relationship with (b), not (a) - so asking (a) to put signals in the DNS or the headers, either one, is pointless.

Unless (as John said) someone can provide a real world non-trivial use case for this, I think we're designing for ghosts here.  A mechanism without a constituency.

Bron.

On Sun, May 17, 2026, at 15:33, Richard Clayton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> In message <CAAFsWK2jS7xs14y+auSpgYwMDgpmrc0szPBwvX3Ww=[e-mail]
> il.com>, Wei Chuang <[e-mail]> writes
> 
> >> >    I propose that the specification or BCP should say that MTAs that
> >> >    need to forward such null recipe, "donotmodify" or "donotexplode"
> >> >    messages onwards for whatever reasons, should delete all prior
> >> >    DKIM2 headers and re-sign the DKIM2 signature as themselves.  This
> >> >    probably means that the above language needs to be tweaked for
> >> >    this.
> >>
> >> That is not good advice for "donotexplode" !
> >>
> >
> >So you'd be for the forensics approach.  My worry, perhaps unfounded if
> >everyone applies section 10.8, is that downstream receivers might
> >misinterpret the earlier signatures.
> 
> you missed my point ... it is perfectly OK to forward "donotexplode"
> email unless you know that it has been exploded (which you may not
> unless a later hop reports that it has done so)
> 
> forwarding email that has been modified despite a "donotmodify" flag
> will always be detectable and forwarding is very likely to end in tears
> so if you must do so then yes, you are going to have to create an email
> that is validly signed -- that might not involve discarding anything,
> you could choose to wrap up the forwarded message in a MIME part and
> send that along
> 
> - -- 
> richard @ highwayman . com                       "Nothing seems the same
>                           Still you never see the change from day to day
>                                 And no-one notices the customs slip away"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
> 
> iQA/AwUBagoYFWHfC/FfW545EQLlZQCg3GdC+cBtYGYmqqD/dG2hqCD2/LsAn1YV
> rSey1q/+RaaOoIWxNm6GcMNK
> =LLSv
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Ietf-dkim mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC
  [e-mail]