Hi Mike, On 7/15/20 6:31 PM, Dotzero wrote: > As part of the original DMARC team and having worked with anti-abuse > for a long time at scale for a large set of websites, I can speak to > my motivation. It's not really about defending brand identity. The > data shows (although it is not mine to share) that end users will > click on anything based on the right social engineering. Love, money, > etc. are powerful motivators. The first thing that DMARC enables is > for a brand/domain to signal to validators/receivers that the domain > has control of it's mail streams and is identifying those mail streams > using the combination of SPF/DKIM/DMARC. This enables receivers to > process those mail streams with a certain amount of confidence. This > leaves open the question of when good domains go bad but that falls > into the realm of local policy on th part of the receiver. I think > anyone who makes an assertion about "DMARC policy" needs.to > <http://needs.to> remember that at best it is a request to > validators/receivers. That's correct, but domains publishing DMARC policy need to bear in mind that some validators/receivers will honor that request and that it can create deliverability problems for their outgoing mail in some situations. > > Yes, the issues of cousin domains, homoglyphs, etc. are thrown out > there as reasons why DMARC is "irrelevant" to solving problems such as > spam or phishing. It doesn't solve spam but it does have an impact on > phishing, if only to push the bad guys to "push reality". If I get a > phishing email from a bank that is not my own, I as an end user am > less likely to fall for that particular phishing scheme. It makes it > easier for validators/receivers to differentiate real from Memorex. > It's also important to recognize that the environment isn't static. > The bad guys are always thinking up new approaches as the > old/currnt ones yield declining results. This evolving context is > sometimes brandished against DMARC as an indicator that it isn't useful. It's not that DMARC isn't useful. We need to consider (and document) the threats that it is effective against (unauthenticated mail claiming to come from a domain from which it should have been authenticated) and those it is not effective against (homoglyphs, display name misuse, etc.). And then we need to consider the collateral damage, such as against mailing lists and their users, and do a cost/benefit analysis to determine whether the benefit justifies the breakage. With 5 years of experience since RFC 7489 was published it's reasonable to revisit these issues with the benefit of that experience. > > My experience with a number of brands/domains that were aggressive in > implementing SPF/DKIM/DMARC as well as other measures, we were able to > drive down abuse against those brands/domains by over 95%. Did the bad > guys continue to test both external abuse as well as probe for > weaknesses that would enable abuse through the systems? Absolutely. > Did they move on to other brands/domains to abuse? Absolutely. > > When Jim asks the question "What problem are we trying to solve?", > perhaps the prior question should be "Who are we?".
Part of the reason I ask that question is because RFC 7489 Section 2.4 says, "DMARC is designed to prevent bad actors from sending mail that claims to come from legitimate senders, particularly senders of transactional email (official mail that is about business transactions)." If restrictive DMARC policies were only applied to domains that were used for transactional email, we wouldn't be having this problem with mailing lists and the like. -Jim
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
