On Tue, Aug 25, 2020 at 5:48 AM Laura Atkins <la...@wordtothewise.com> wrote:
> > > On 24 Aug 2020, at 23:34, Douglas E. Foster < > fosterd=40bayviewphysicians....@dmarc.ietf.org> wrote: > > Something seems inconsistent: > > - The people who have implemented DMARC do not see any significant > problems, and as a result they are not interested in a third-party > authorization scheme. > > - Yet adoption is very slow, especially for anything other than p=none > > Are we to assume that mailing list compatibility explains the slow > adoption? If not, what other obstacles do we need to be considering? > > > I don’t believe mailing list compatibility is a primary reason for slow > adoption, although I do think it’s a contributing factor. To my mind the > biggest obstacle to adoption of restrictive policies is the expense of > implementation and the lack of return for that investment. > > Implementing DMARC, particularly for larger companies who want to do it > correctly, is expensive and resource intensive. It is a multi-month process > to identify all the legitimate sources of mail, create alignment or move > vendors and set up the correct reporting mechanism. You can, and I do > recommend, outsource this to one of the vendors who does this well. Not > every company outsources or has the resources to do this correctly > internally. A client from last year was told they had less than a week to > go from no DMARC to p=reject. Unfortunately, the IT directive came with > nothing more than a “publish v=DMARC1; p=reject in your DNS.” Client lost > days worth of mail due to a lack of direct alignment even though they were > using their own domains in SPF and DKIM. Checking now, client still isn’t > collecting reports, but has backed down to p=quarantine. > > A restrictive DMARC record requires a large, up-front commitment of > resources. It also requires ongoing resources for monitoring and > understanding the reports and the ability to be able to address any > problems that show up in the reports. > > For a lot of companies, the benefit to publishing restrictive DMARC policy > is minor. It stops bad guys from directly forging their domain, but doesn’t > stop your brand being phished or your executives from being spear phished > using cousin domains or taking advantage of the 5322.from comment. It also > disrupts normal business processes as we’ve been discussing on the list > here. To borrow an example from John Levine, a restrictive DMARC policy is > preventing employees at a large company from participating in industry > specific mailing lists; participation which is part of their actual job. > > I believe a lot of the very slow adoption is folks inside companies > looking at the cost of implementing restrictive DMARC records and the > benefits to implementing restrictive DMARC records and deciding there just > isn’t enough benefit to justify the expense. BIMI is an attempt to bring > more benefit to the table, but I’m not sure even that is enough to justify > the overall expense to a lot of corporations. > > laura > I agree with many of Laura's observations. One other issue is that DMARC adoption is typically advocated by security and/or IT. When put against competing demands for resources and potential projects in an organization, it often gets moved down the priority list... until the organization is being abused in a way that they feel DMARC might help mitigate. Then there is a rush to implement, often with painful outcomes. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
