On 8/13/20 4:53 PM, dotz...@gmail.com wrote: > Wrong answer. If the vendor is uncooperative then fire the vendor. 4-5 years > ago it was difficult to find vendors who were willing to deal with DKIM and > able to do a good job in implementing. The common mantra was "how does this > fit into my business model". These days I would consider it table stakes.
DKIM, DMARC policy conformance, or any practical email functionality are rarely considered in procurement decisions. Only recently did I manage to get some of these requirements into our organization's RFP templates. It really hasn't made any impact on procurement decisions, which are made by people who don't understand the nuances of email to the extend that they can tell if the vendor actually meets the requirements. Even if I were included on the evaluation team for every procurement (a job I do not want) it would be rare that lack of DKIM support would be enough to weigh negatively on a decision. People like me only get called in after the system is deployed in production and they run into problems getting email delivered. For one recently-procured (inventory management software) vendor, I had to coach a poor sysadmin through how to set up Postfix to relay-rewrite their own application's email so that it wasn't able to outright spoof (for lack of a better term) the address of any end-user-free-hand-inputted address. Their own app dev team didn't feel like it was important enough to learn about DKIM/SPF/DMARC and kept confusing the changes they needed to make for email authentication with TLS 1.0 deprecation. "It's in our next release" they kept saying. Companies like that will just check the "we support DMARC" on the procurement form because they don't know enough to understand that they don't. Jesse _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
