Re: [dmarc-ietf] non-mailing list use case for differing header domains
I have seen Jesse mention something along these lines a couple of times: * Departments sending transactional email - move them to dedicated subdomains (this is where really complex institutions would benefit from walking the domain tree instead of always inheriting from the org domain) Is inheritance walking the domain tree a topic that has already been discussed ad nauseam? This seems like an interesting point of discussion, but I also haven't been participating on this list for ten years and don't want to get into it if this is a topic everyone is tired of or that has no possibility of change. Thanks, Autumn Tyr-Salvia atyrsal...@agari.com Agari Principal Customer Success Engineer From: dmarc on behalf of Jesse Thompson Sent: Monday, August 17, 2020 4:39 PM To: John Levine ; dmarc@ietf.org Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains On 8/7/20 9:32 PM, John Levine wrote: >> We need spoofing protection for all of our domains without being told we're >> misdeploying. > > I would be interested to better undertstand the meaning of "need" > here. It is my impression that most people vastly overestimate how > much of a phish target they are. Paypal and big banks certainly are, > other places, a lot less so. (Sorry, I was on a much-needed vacation.) Ok, that's fair, I should have realized that one was over-stated. *Need* would imply that domain-spoofing is more common than it is in reality. Cybersecurity-minded folk in EDU tend to equate observed inbound phishing with spoofing (even though most phishing is spoofing the display name and message bodies, not the domain) and conclude that they *need* DMARC without really understanding the nuances. Given the opportunity that DMARC marketing promises, they definitely *want* inbound DMARC enforcement for domain-spoofing of inbound mail (they'll defer to the email-minded folk to figure out the local policy exemptions, ARC, etc), as well as *want* domain policies that prevent the potential domain spoofing scenarios of owned domains (again, the email-minded folk will figure out how to actually "misdeploy" DMARC).. To them, it's just a checkmark towards some "maturity" benchmark that they use to compare to their peers. Email-minded folk in EDU, knowing that DMARC doesn't really have much practical application to phishing, like having the observability that DMARC provides, as well as the hammer that moving past p=none provides as a way to coerce their complex, decentralized institution into a more sustainable operation: * Departments sending transactional email - move them to dedicated subdomains (this is where really complex institutions would benefit from walking the domain tree instead of always inheriting from the org domain) * People sending user email from random places - move them to authenticated submission (preferably OAuth - since basic authentication is the reason why so many passwords are exposed) The latter scenario is interesting because a single user sending from a random place doesn't really show up in DMARC aggregate reports. It may show up in forensic reports, but it is easily lost in the noise. (SPF macros might be another way to get fine-grained observability, but that's a privacy leakage IMO.) In the end, it still results in: * That person wouldn't end up on our radar for communication * That person wouldn't understand what the message is about, even if we did communicate with them * That person wouldn't comply, even if they understood * Once enforcement is in place, that person will complain and leverage every ounce of their political influence to resist. (It's really fun when your own users threaten lawsuits against you - that doesn't happen in Corporate IT.) I'm kind of rambling now, I see. Hope you find it enlightening, regardless! Jesse ___ dmarc mailing list dmarc@ietf.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7Catyrsalvia%40agari.com%7C07fe631db10e49cfa46508d84306d0b9%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637333043846011888&sdata=GEKpu8y3KvA7Zkt0VJmeKz4KPwvSay51cj5SDniQAUo%3D&reserved=0 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
"I do get the instinct to be proactive but if you’re going to be proactive, get ready to take the time and, if outside help needed, the money to do it without breaking legit mail." -Admittedly, that's where my bias comes in. My job is working with organizations that have paid my employer for me to be that outside help, so it's rare for me to see how badly it can be done by people setting restrictive DMARC policies without knowing what they're doing. Best, Autumn Tyr-Salvia atyrsal...@agari.com Agari Principal Customer Success Engineer From: Neil Anuskiewicz Sent: Wednesday, August 12, 2020 3:17 PM To: John Levine Cc: dmarc@ietf.org ; Autumn Tyr-Salvia Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains > On Aug 7, 2020, at 12:12 PM, John Levine wrote: > > In article > > you write: >> 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. > > I was with you up until that sentence, since it trivializes the real > problems that overly strict DMARC policies cause. > > Just yesterday I was sorting out a problem with people trying to > finish editing a revised IETF standard about real-time web > applications. Some of the authors' messages were disappearing, > apparently at random. I saw what the problem was, one of the authors > is at a big company whose IT department insists on p=reject (and has > blown off complaints from fairly senior people about the problems it > causes), the other uses an MIT alumni address that recently moved its > hosting to Microsoft without telling anyone that the new host enforces > DMARC policy while the old one didn't. > > My guess is that MIT figured Microsoft will host this for free, that's > great, totally unaware that some of its users' mail would silently > break. > > I told them as a workaround they needed to directly cc each other when > they send anything to the group list, but the whole thing is a > self-inflicted wound. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmarc&data=02%7C01%7Catyrsalvia%40agari.com%7C2388c4693f9a41d84d4308d83f0d7ab4%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637328674420006184&sdata=u2xp7UMS7OHzkkyzHeoKa9Ri3w8v7sjJWvW%2BXuepmj4%3D&reserved=0 When mail breaks it’s more than an inconvenience. In business it can materially affect people’s livelihoods. I do think that sometimes people don’t take p=reject seriously enough, and don’t realize how much time and monitoring and prep it takes. I mostly work with smaller entities but I advise staying at p=none of the time unless there’s spoofing. Otherwise, it’s reporting only, watch the reports, and take action if and only if there’s a problem. I do get the instinct to be proactive but if you’re going to be proactive, get ready to take the time and, if outside help needed, the money to do it without breaking legit mail. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
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 on behalf of Dotzero Sent: Wednesday, August 5, 2020 12:52 PM To: Jesse Thompson Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains On Wed, Aug 5, 2020 at 12:39 PM Jesse Thompson 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 >> 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 tran
Re: [dmarc-ietf] non-mailing list use case for differing header domains
To Todd's point, I think the answer on which policy would be applied at least needs to be predictable. If one receiver chooses one policy and a different receiver chooses the other policy, that is going to make it significantly more complicated for complex organizations to implement a DMARC p=reject or even p=quarantine policy. Thanks, Autumn Tyr-Salvia atyrsal...@agari.com Agari Principal Customer Success Engineer From: dmarc on behalf of Todd Herr Sent: Tuesday, July 28, 2020 1:58 PM To: John R Levine Cc: IETF DMARC WG Subject: Re: [dmarc-ietf] non-mailing list use case for differing header domains On Tue, Jul 28, 2020 at 4:30 PM John R Levine mailto:jo...@taugh.com>> wrote: On Tue, 28 Jul 2020, Todd Herr wrote: > Using the Sender header and the "snd" bits in the DMARC policy for > firstbrand.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffirstbrand.com%2F&data=02%7C01%7Catyrsalvia%40agari.com%7C92171061501e4c0b556008d833390787%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637315667319827245&sdata=1AHw64v72T7eJ%2BNrnkkUsSnky%2F1H2CqV3tA1t1X0FvM%3D&reserved=0>, > DMARC would pass for the Sender domain and fail for the > From domain. > > Which verdict gets applied to the message? I believe the reasoanble answer is both, and the filtering engine evaluates both based on their reputations. Two responses, two different but equally valid answers, the other (Dave's) being "receiver discretion", which *could* be an umbrella term to include John's answer, but would certainly also include other applications of rules for this scenario. Note that I'm not at all opposed to the idea put forth in https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-crocker-dmarc-sender%2F&data=02%7C01%7Catyrsalvia%40agari.com%7C92171061501e4c0b556008d833390787%7C05773123385e420d844ef01aee5e37ab%7C0%7C0%7C637315667319827245&sdata=6Z2zUXQD8CB14mF9Tw9bNDVb7k5dyqUAez%2BJ%2B8TPYUs%3D&reserved=0> but I do believe that there will have to evolve a very limited set of known and expected possibilities for how such messages will be handled, or else wails will be wailed, teeth will be gnashed, and garments will be rent, especially among those trying to do the right thing when sending email and the deliverability people they employ. -- Todd Herr | Sr. Technical Program Manager e: todd.h...@valimail.com<mailto:todd.h...@valimail.com> p: 703.220.4153 [https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6LS0Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8ChT2x5EcZV3rjz19-Dx9rESL] This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] non-mailing list use case for differing header domains
Hello, I recently had a conversation with Dave Crocker about proposed changes for DMARC, and mentioned a use case to him that is not well served by the current situation that is not a mailing list. He said it might be useful to share this to this list, so I'm writing it out here. A customer of mine is a large financial services company. Like many in that field, they have acquired several other companies over the years, and now operate multiple different brands, which send email using different domains.. While many companies like this maintain one primary domain for corporate email and others only for marketing purposes, this company maintains multiple distinct domains even for corporate workplace email. The challenge is that they have many administrative assistants who send out meeting calendar invitations on behalf of the executives they support, and the executive and the assistant do not always use the same email domain. The resulting messages are not aligned, so they fail DMARC. To put it another way: * assist...@firstbrand.com is organizing a meeting for execut...@secondbrand.com * assist...@firstbrand.com sends out a calendar invite from their own messaging client, using execut...@secondbrand.com in the From: field * The resulting message uses execut...@secondbrand.com in the friendly From: field, but firstbrand.com in the SMTP MAIL FROM domain, so the headers are no longer aligned for SPF. * Both firstbrand.com and secondbrand.com are set to DMARC p=reject. * Messages like this are then rejected by receivers that validate DMARC results. Whenever possible, they tell me they change the assistant's email domain to match the executives they support, but as people leave or change departments, they sometimes end up with assistants supporting executives across multiple different domains, so they can't ensure they always have the same domain. Maybe the ultimate answer for this customer and others in a similar situation is simply that this is a use case that can no longer be supported due to evolving security needs, and yet if that's the case, I thought it would be helpful to share a real world scenario that is currently impacted that isn't part of the previously existing discussion around mailing lists. Thanks, Autumn Tyr-Salvia atyrsal...@agari.com Agari Principal Customer Success Engineer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=reject
Hello Michael, Consider this scenario: Friendly From: @yourbank.com SMTP MAIL FROM: @spammer.ru DKIM d=spammer.ru SPF gets checked at the SMTP MAIL FROM domain, and DKIM gets checked at the d= domain. Either or both of these could pass authentication, but that would not mean the message is legitimately from yourbank.com. DMARC was intended to tie together the backend server information with the friendly From: address to prevent abusive spoofing like this, which is very common. Thanks, Autumn Tyr-Salvia atyrsal...@agari.com Agari Principal Customer Success Engineer From: dmarc on behalf of Michael Davis Sent: Monday, March 18, 2019 12:48 PM To: dmarc@ietf.org Subject: [dmarc-ietf] p=reject If a sender's IP is in SPF, so SPF passes; and the applied DKIM signature is successfully decrypted, so DKIM passes; what good is checking alignment and rejecting a message? I have had Adobe and Cloudflare automated system emails rejected based on those senders' DMARC policy, after SPF and DKIM pass.. These emails were regarding password resets and come from servers that do not equal the spoofed address domain. It would seem that if the sender is approved according to SPF and verified according to DKIM that alignment being a reason for rejection post authenticas is an exercise of absurdity. Please help me understand otherwise. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
