On Sun, Jun 7, 2020 at 6:58 AM Douglas E. Foster < [email protected]> wrote:
> 1) The original assertion, that DMARC creates a conflict with prior > specifications, appears to be undefended and incorrect. For From > Addressing, It merely establishes some boundaries that the sender and the > recipient choose to consider appropriate. For DKIM, it creates a > use-case for a technology that was initially defined without any use cases. > Consequently, I think this topic is ready for closure. > I claim your assertions here are contradictory. Specifically, by establishing "some boundaries", it is creating a conflict with prior specifications which established none, possibly intentionally. 3) Some of the discussion has been about how to prevent soclal engineering > of the recipient user. This is an important topic, but not directly > related to the project. IETF would do well to establish some > recommendations about how MUAs should behave, so that trust data can be > displayed to the user. A typical user will have access to at least three > different email clients: one on his cell phone, a product-specific web > page, and a desktop product like Outlook or Thunderbird. If I wanted an > organization policy that controlled when Friendly Name was displayed or > DMARC status was displayed, I would have to find and distribute plug-ins to > all of these products. As best as I have been able to tell, no such > plug-ins even exist for Outlook and the other products do not accept > extensions. There is an opportunity here for valuable standardization. > The IETF has routinely punted, at least in the email space, on the idea of prescribing or proscribing user interface behaviors because we are protocol engineers, not human factors experts. Are you claiming that's changed? -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
