Tactically, what I meant was "IETF should be able to ensure that IETF messages are only released with verifiable IETF signatures".
This would mean that either the first signature is not applied, the message is not altered after the first signature is applied, or the first signature is removed after the message is altered. The current configuration leaves open the suspicion that IETF has rogue software operating in its environment. I am aware that the DKIM specification says to treat an unverifiable signature as a non-signature. This is not a sufficient reason to release your own organization's signatures onto the internet when you can or should know that they will fail validation. Doug Foster -----Original Message----- From: Dave Crocker [mailto:[email protected]] Sent: Friday, May 31, 2019 12:41 AM To: [email protected] Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion On 5/30/2019 7:49 PM, Douglas E. Foster wrote: > I rather hoped that IETF would be the poster-boy for list processing > done correctly. "Correctly"? A message to a list is 'delivered' to the list. As in, it goes to the specified addresse... the list. A message from a list has been re-posted by the list. There are no constraints on the changes that are permitted to a message, before it is re-posted. There are no specifications that limit or direct the behaviors of a list processor. Different groups want and probably need different behaviors by a list processor. Periodic efforts to create such constraints have failed. So while it would certainly make things easier to have list processors behave in a simple, consistent manner, there's ample evidence that ain't gonna happen. If you can link the 'correctly' you are suggesting, to some documented, community consensus, please cite it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
