On Thu, Jun 22, 2023 at 6:32 AM Todd Herr <todd.herr= [email protected]> wrote:
> Marty also has the right to engage a third party to send the mail (again, > as conveyed by their employer), mail that Marty and others at Marty's > company will create. The third party here is most commonly referred to, in > my experience, as an Email Service Provider (ESP), but this is just one use > case. The ESP knows how to DKIM sign messages, and can even do so using the > domain of Marty's employer, so long as Marty is able to get the public key > published in DNS. > We thought about this during the early DKIM days. It was called out more than once that at sufficiently large organizations, the email people and the DNS people are not certain to be part of the same organization. That's certainly true where I work. And at a subset of the largest of those organizations, the email people and the DNS people don't trust each other either, so they sometimes make it harder for one to tamper in the space of the other. We tried to keep this in mind while designing how DKIM could function. I concur that this isn't really a problem for either working group to solve as part of a standard, but there might be room for some suggestions if either one ends up producing a best practices document. The open source DKIM package I developed included a simple tool that would generate a properly formed TXT record and associated comments suitable for inclusion into a zone file, but there was feedback that it was still error prone. It also included a script that, once you had published a DKIM record, would confirm that your signing key and the public key now in the DNS matched, so signatures should work. I had two thoughts over the years about other things to try: (1) Instead of generating a DNS TXT record for someone to cut and paste, output a complete "_domainkey" zone file to simply move into position, i.e., by copying files rather than strings. This is less prone to corruption because copy-paste isn't part of the process. (2) Make use of protocols like DNS UPDATE (RFC2136) that could allow DKIM key generation tools to insert new records directly into the primary authoritative server. This is even less prone to error or corruption because the human is almost totally removed from the process. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
