On Sun, May 17, 2026 at 7:36 AM Richard Clayton <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In message <[email protected] > il.com>, Wei Chuang <[email protected]> writes > > > I also agree that there needs to be more clarify around null > > recipes and their scoping. One thing that is said around > > "donotmodify" is that "A system that, by local policy, ignores this > > request MUST NOT allow the message to be forwarded on to any MTA > > outside its control." There should be similar language for systems > > that use null policies. > > by null policies I think you mean p=none. I don't think the DKIM2 spec > is the correct place for such a discussion. Sorry I was being careless. That is supposed to be "null recipes". > > > 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. Perhaps add a note of caution in the BCP as section 10.8 contains "SHOULD be rejected". Even with stronger language like "MUST be rejected", I suspect some forwarders will still send results onward. This might be a scenario receivers simply have to be aware of, and forensics is the right approach. -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
