Kurt Andersen writes: > I have to confess that I have not (yet) waded through the details > of TPA or ASL or ATPS, but from a corporate perspective, it would > be extremely unworkable for any but the smallest company to manage > DNS records to whitelist every list server on the internet that my > employees would happen to use.
I don't see that a small company, or any company, would want to. Your employees are representatives of the organization when using (most of) your subdomains and your main domain, and "p=reject", with no mitigation on your part, seems perfectly reasonable to me.[1] Use a subdomain like just-for-fun.example.com or list-post.example.com with "p=none" if you want to permit personal posts to 3rd-party mailing lists. If companies can agree on a single such subdomain (or even 5 or 10 of them), the MUAs-for-people-prone-to-entering-passwords- in-email-forms can recognize it and treat that subdomain as suspicious. Eg, disabling all links in the email, or redirecting to a page which explains why clicking on these links is dangerous. If your employees find it tedious to switch return addresses, let them use XEmacs![2] The idea is that Yahoo! and AOL can use these protocols to mitigate the damage they are doing, not just in actual DoS, but in causing people to run around saying "The sky is falling! The sky is falling! Let's change the semantics of RFC5322.From!". I find the thought of "p=reject" domains putting their own resources on the line appealing. Footnotes: [1] The exception would be the small set of vendors like QuickBooks who provide you with value-added services, so that you have a business reason for whitelisting them. [2] Yes, I know what happened to Marie Antoinette. Just kidding. However, Emacsen-based MUAs are proof of concept. It is not that hard to write an MUA smart enough to automatically switch personalities when posting to a list or writing home to Mom. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
