On 7/22/20 5:55 PM, Jim Fenton wrote: > These get to the heart of the problem: DMARC policy was designed for > official mail that is about business transactions. If that was the way > it is actually used, we wouldn't be having this problem. But it was > oversold, and it is being used in use cases (like on domains that have > mailing list users) that were not intended.
Yes. The cybersecurity IT community (at least, in Hi-Ed) largely don't know much about email's technical nuances. But they they know that email phishing is a problem, and CISOs demand a solution. They have their information sharing communities (ISACs), where email specialists are generally not included, to share knowledge and continue grasping for solutions to phishing. Enter DMARC marketing: phishing is a spoofing problem and you're vulnerable unless you protect your domain with DMARC. Cybersecurity IT tend to see things like DMARC as a checkbox towards compliance. Once that box is checked (varying definitions) == job complete (email specialists are left to clean up the mess). Since DMARC was ostensibly invented by the email community, there's not much room for local email specialists to convey that it's not a complete solution for phishing, and may not be worth implementing on domains used by end-users. Momentum suggests that it's easier to just join the bandwagon, move for ward with DMARC for every domain (to take advantage of the benefits it offers), and hope that Intermediaries can find a solution. > I'm not convinced that this is a problem that has a satisfactory technical > solution. I think there may be technical and non-technical techniques that can be pieced together to arrive at a satisfactory solution, depending on the individual/evolving circumstances. What's lacking is clear guidance for Intermediaries; both for people who provide software/platforms, and for those installing and configuring them. What is the best avenue for providing guidance? I mean, this isn't just a problem for MLMs. Office 365 utterly fails at mailbox-level forwarding in a DMARC friendly fashion. Their latest announcement to tenant admins suggest that they're more likely to coerce their customers' end-users users to stop forwarding via SMTP altogether. Maybe that's the only generic solution for that type of Intermediary (whereby ARC might be an alternative solution to forwarding between trusted institutions). Is it satisfactory? Not to end-users who want to forward their email. Maybe the conclusion is that SMTP isn't even appropriate for many types of forwarding anymore, but rather pull-based OAuth solutions are more sustainable. This solution is increasingly compatible with the mailbox hosting platforms, but isn't widely implemented by the receiving end of the equation. Is there any point in recommending something like that as a solution as a way to move the industry in that direction? Or does something like this just tend to sort itself out? Jesse _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
