What I find very interesting about this email from Jesse, and Mike's response is that I hear these words coming from two very different experiences of deploying DMARC.
In my role doing onboarding at Agari, I have worked with many different organizations on their DMARC projects. I have worked with numerous corporate groups, as well as governmental organizations, nonprofits, and universities. Universities operate with a somewhat different set of expectations than other groups in ways that make DMARC additionally challenging. Here are a few things I have learned implementing DMARC for multiple universities: * Universities have a significantly higher degree of user and use case turnover than other organizations, by a lot. There are new students and staff every term, and many more of them will use their email address to send out email over various third party tools. In the corporate world, sure there are employees coming and going all the time, and new projects, but there is a much greater degree of stability in terms of systems sending out email. * University IT has much less control over their users than corporate IT. In corporate IT, it is not unusual for IT leadership to make decisions on what applications will and will not be supported, and to have general support for this from the top. In higher education, IT teams seem to frequently be told that they must support whatever their users request, and have very little authority. * Most universities serve a greater breadth of use cases than most other organizations. Consider an organization that is a fundraising nonprofit, scientific research group in multiple disciplines, hospital, mental health clinic, employer with HR tools, housing coordinator, childcare coordinator, gym, sports arena, transportation system, provider of continuing education to certified professionals, press agency, mailing list provider, forwarder, etc. all in one. There are a lot of niche tools that can send email in each of these different use cases, but universities are the only place I see so many of them all together. * Universities are highly decentralized. It seems like every major school inside a university (school of public health, school of humanities, etc.) has its own policies and culture, and sometimes its own IT staff. * Universities tend to have more legacy technology than other organizations (except government). The reason I mention all this stuff is that I feel like some of what is being suggested here misses this reality. Mike said, "You need buy-in from senior management for any email authentication efforts. When you add up the costs of customer support contacts for dealing with fraudulent email claiming to be from your organization, reputation damage, etc., management becomes more willing to buy into a comprehensive strategy." - in the higher education world, I don't see it working like this. IT staff can get enough buy-in to decide to work on DMARC as a project, but the costs of support contacts are likely spread out over multiple groups in a way that is very hard to quantify at a higher level, and even if they were to consider that, they would still be more likely to say that a comprehensive strategy is good and all, but it still matters more to them that good old Professor 1984 can still use his favorite application even though it doesn't conform to modern security standards. I feel like what is happening sometimes is that central university IT is trying to drag their whole institutions into a more secure posture before anybody in a position to stop them fully understands what's going on lest they be told to stop because it might make things a little inconvenient. Many universities do not attempt DMARC at all, so I think any work we can do to make it easier on them would encourage greater adoption. Thanks, Autumn Tyr-Salvia atyrsal...@agari.com Agari Principal Customer Success Engineer ________________________________ From: dmarc <dmarc-boun...@ietf.org> on behalf of Dotzero <dotz...@gmail.com> Sent: Wednesday, August 5, 2020 12:52 PM To: Jesse Thompson <jesse.thompson=40wisc....@dmarc.ietf.org> Cc: IETF DMARC WG <dmarc@ietf.org> Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson <jesse.thompson=40wisc....@dmarc.ietf.org<mailto:40wisc....@dmarc.ietf.org>> wrote: On 8/4/20 11:52 AM, Alessandro Vesely wrote: > On 2020-08-04 6:10 p.m., Dotzero wrote: >> On Tue, Aug 4, 2020 at 11:39 AM Jim Fenton >> <fen...@bluepopcorn.net<mailto:fen...@bluepopcorn.net>> wrote: >>> On 8/2/20 5:43 PM, Douglas E. Foster wrote: >>>> As to the transparency question, it should be clear that there will be >>>> no simple solution to the ML problem. >>> >>> Actually, there is: If your domain has users that use mailing lists, >>> don't publish 'reject' or 'quarantine' policies. Generally this means to >>> just use those policies for domains used for transactional email. >>> >>> Unfortunately we seem to be focused on very complex technical solutions >>> to a misdeployment problem. I've never heard this misdeployment viewpoint in the context of M3AAWG, so that might be a good audience to validate the viewpoint that users' domains can't benefit from p=quarantine|reject. Perhaps it should be included in a BCP? Maybe it is, and I'm misremembering? Granted, I've only been a member for a few years. Maybe it was a common understanding years ago and no one talks about it anymore? Not a knock on M3AAWG but many of the members are more interested in deliverability than anti-abuse. The Sender side of M3AAWG is dominated by ESPs rather than Brand Senders. I say this as the Founder and Chair of Brand SIG for 10 years until I left my employer that was a member of M3AAWG. For example, when I was invited by the technical committee to present our strategy and challenges deploying DMARC for our institution, no one told me we were misdeploying. The session was pretty well attended, and I don't think I put everyone to sleep. Now I feel like my speech was counterproductive because I may have encouraged others to misdeploy DMARC too. You were presenting what you did. It may or may not have been counterproductive. >> There is another solution. Move users to a separate domain from the domain Long ago we put users on our org domain as a way to unify users (in a very decentralized institution) under a single domain identity, and that branding decision is not going to be undone, politically. Any project to move users from one domain identity to another is a huge lift; it takes a lot of time, effort, and never actually completes due to stragglers with very legitimate reasons to not give up sending from their old address. I implemented for an Enterprise with large ecommerce/social sites and 20k seats. The only people that were allowed to keep accounts on the primary domains were people who directly supported the websites and they were not allowed to use those accounts for anything other than supporting the websites. They had accounts at the other domain just as all the other users. I think that end-users would rather see their list mail be rewritten than be told to change their identity. I know that some people on this list think that the domain in the from header isn't commonly visible anymore, but the domain is extremely important to users' sense of identity. Their identity at that organization is subject to the determinations of the organization. It is amazing how quickly after a one time transition that users get used to their new "identity". >> your transactional mails are sent from. You can also put users on a >> separate subdomain. To the idea of clean separation: We only encourage (without DMARC there is no way to enforce) subdomains for transactional email despite "brand minded" people insisting on using the org domain (or just using it without asking). Despite everyone having an address in the org domain, we still have many users using legacy subdomains, and some of those subdomains are mixed-use. You need buy-in from senior management for any email authentication efforts.. When you add up the costs of customer support contacts for dealing with fraudulent email claiming to be from your organization, reputation damage, etc., management becomes more willing to buy into a comprehensive strategy. DMARC is great for getting visibility on this "separation" problem. It's not until we moved past p=none that we could get any sticks behind our carrots. What I'm saying is that mixed-use domains are common and they proliferated due to the lack of domain alignment enforcement prior to DMARC. Even when there is intention by IT to separate the use cases, they need DMARC to get both the visibility and the manageability/enforcement. If it is only IT pushing this, you are probably doomed to failure. I've observed other universities using their single org domain for everything, and they don't find out they have a problem until they try to implement DMARC. It's easier for them to move the transactional email to subdomains than to move users. That is, unless they just give up on the idea of DMARC altogether. Organizations make choices based on perceived benefits and costs. This might be a stretch, but I think the "DMARC is different for user vs transactional domains argument" dovetails with the need for sp to walk the domain tree. If the assertion is that the domain with users is fundamentally different than domains used for transactional email, and most institutions use their org domain for their users, and subdomains are a mixed bag of varying use cases, then the org domain's DMARC policy isn't the best candidate for inheritance. The assumption was/is that the organizational domain most closely tracks the risk for abuse and is therefore the one that most needs protection. Therefore inheritance should be the rule rather than the exception. It also means you don't have to walk the full tree. You only need to check the base domain if the subdoain doesn't specify a policy. > Yet another solution would be to not use DMARC. The status quo ante. > > While p=none is a technically valid position, there seems to be a > demand of a mail infrastructure where spoofing is not allowed. Not only a demand, but a requirement: https://cyber.dhs.gov/bod/18-01/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcyber.dhs.gov%2Fbod%2F18-01%2F&data=02%7C01%7Catyrsalvia%40agari.com%7Cd897635e2c654363de9608d839791b99%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637322539599239026&sdata=8hnuQvc7CtCUIyzbwMLcy5C4Jtypn969G%2BV6vAvkSG8%3D&reserved=0> I don't think DHS got the memo about misdeploying DMARC, either. I know that around 2018, the person maintaining the MLM for our astrophysics center had to scramble to implement header munging because of all of the ..gov's publishing p=reject The .gov space has an interesting and long history with regard to email authentication. In 2011, Pat Peterson (Agari) and I were asked by EOP (Executive Office of The President) to create and give training on email authentication for .gov that was turned into a virtual training environment that was available for all government employees. The specific impetus were a series of incidents that included fake malicious White House ecards purporting to be online Christmas cards that were sent to government contractors and others. Required authentication for .gov domains moved forward in fits and starts up to the point of the DHS mandate. DHS approached the use of DMARC and authentication as a blunt one size fits all instrument. The reality is that the devil is always in the details. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
