[dmarc-ietf] Re: New attack leveraging DMARC None
> On May 8, 2024, at 12:59 PM, John Levine wrote: > > According to Mark Alley : >> -=-=-=-=-=- >> >> p=none is one solution, the other ( interoperable method) is to exempt the >> traffic from whatever process is breaking DKIM (i.e. external subject/body >> warning tags, URL rewriting, etc.). But that's a per-customer fix. > > That would require getting the customer to understand that they're causing the > problem and to spend money fixing it, rather than saying "your mail is > broken." > > Good luck with that. Also remember that until DMARC came along, this > all worked just fine. That’s the easy part in my experience. A good conversation addressing concerns and getting buy in from previously skeptical people is easy in conversation. In my experience the misconceptions are often there yet shallow. They’re easily fixed misconceptions from the whirlwind of information, hype, and I’ve even seen panic. I’m not wise enough to know how to counter that chaotic noise machine at scale. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: New attack leveraging DMARC None
> On May 7, 2024, at 6:09 PM, Mark Alley > wrote: > > >> >> On 5/7/2024 7:00 PM, Dotzero wrote: >> >> https://www.ic3.gov/Media/News/2024/240502.pdf >> >> This was released this past week by the FBI. Although we are in last call, I >> have to wonder if a) the attack itself, and/or b) the government >> recommendations regarding policy might impact DMARCbis in any manner. I've >> only just started thinking about the attack itself and potential >> implications. >> >> Michael Hammer >> > While the subject is interesting, in my eyes, Business Email Compromise > (BEC), and a non-preferential DMARC policy disposition published by the > spoofed domain owner aren't an issue with the DMARC mechanism itself. The > receiving mail system did exactly what the domain owner requested with > p=none, no disposition was taken on email(s) failing DMARC. > > From an alternate point of view, one might consider how this policy could be > more broadly "exploitable" as a side effect now that the internet email > ecosystem is inundated with p=none DMARC records by domain owners just doing > the bare minimum to meet ESP sender requirements, but that's still not a > problem with DMARC itself. > > Addressing this issue - perusing Section 5.5.6, is there anything else we > could add that would be acceptable language in an Standards track document to > encourage urgency behind a transitory state of p=none use by domain owners? > Would that even make sense to do? (Legitimate question for the WG) > > > > - Mark Alley > Yes,my side effect of the rush to p=none or bust to check some boxes comes from an incentive just as incentives brought us DMARC snake oil. I’ve noticed that friends of mine much smarter than me don’t know anything about email authentication. Even people who work in email often seem to avoid it. So the incentive to jump through hoops was kind of unfortunate but I suspect that the half backed incentives toward p=none as a copy and paste are part of a longer term plan. The next set of incentives seem likely to encourage enforcement at a pace that doesn’t turn the apple cart over on small businesses and the like. There kind of needs to be a lot of clear communication which is relatively easy as it doesn’t take long to grok the basics if you’re interested at all. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: New attack leveraging DMARC None
> On May 7, 2024, at 7:19 PM, John Levine wrote: > > It appears that Scott Kitterman said: >>> Addressing this issue - perusing Section 5.5.6, is there anything else >>> we could add that would be acceptable language in an Standards track >>> document to encourage urgency behind a transitory state of p=none use by >>> domain owners? Would that even make sense to do? (Legitimate question >>> for the WG) >> >> I don't think the claim that p=none is "transitory" is at all generally >> correct. It will be in some cases and not others. > > I have to agree. I still have no plans to use anything other than p=none > on most of my domains. > > Also, it's not like p=reject is a magic bullet. It makes some kinds of > mail forgery harder, but it does nothing about lookalike domains or > attacks that use the fact that most mail programs don't even show the > author's address. > > Please, let's not get distracted and let's finish up. Dmarc is the best tool for the job. There are other tools to fight lookalike spoofing. I haven’t heard a serious claim that dmarc is the miracle cure. You might say it kind of fits the Unix philosophy of a tool that does one thing well. I think there’s been hype. But the good news is it’s easy to explain to someone the limits of DMARC as once you get it it makes intuitive sense. The issue isn’t with DMARC’s excessive claims. It’s some of DMARC’s advocates. I think of DMARC as a key puzzle piece. I feel we have a tendency to think less of DMARC, even undervalue it, because of the behavior of a few overzealous advocates. ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: New attack leveraging DMARC None
> On May 8, 2024, at 3:48 AM, Laura Atkins wrote: > > > >> On 8 May 2024, at 02:25, Scott Kitterman wrote: >> >>> On Tuesday, May 7, 2024 9:09:02 PM EDT Mark Alley wrote: On 5/7/2024 7:00 PM, Dotzero wrote: https://www.ic3.gov/Media/News/2024/240502.pdf This was released this past week by the FBI. Although we are in last call, I have to wonder if a) the attack itself, and/or b) the government recommendations regarding policy might impact DMARCbis in any manner. I've only just started thinking about the attack itself and potential implications. Michael Hammer >>> >>> While the subject is interesting, in my eyes, Business Email Compromise >>> (BEC), and a non-preferential DMARC policy disposition published by the >>> spoofed domain owner aren't an issue with the DMARC mechanism itself. >>> The receiving mail system did exactly what the domain owner requested >>> with p=none, no disposition was taken on email(s) failing DMARC. >>> >>> From an alternate point of view, one might consider how this policy >>> could be more broadly "exploitable" as a side effect now that the >>> internet email ecosystem is inundated with p=none DMARC records by >>> domain owners just doing the bare minimum to meet ESP sender >>> requirements, but that's still not a problem with DMARC itself. >>> >>> Addressing this issue - perusing Section 5.5.6, is there anything else >>> we could add that would be acceptable language in an Standards track >>> document to encourage urgency behind a transitory state of p=none use by >>> domain owners? Would that even make sense to do? (Legitimate question >>> for the WG) >> >> I don't think the claim that p=none is "transitory" is at all generally >> correct. It will be in some cases and not others. > > I’m currently dealing with a client that sends notification emails to their > customer businesses. Those businesses forward the messages out to their > employees. DMARC breaks during the forwarding process - my guess is that it’s > due to the business filtering appliances modifying the body of the message on > inbound - adding “external” or modifying links. > > The mail is all isolated on a subdomain that’s only used for these > notifications. The domain had p=reject but a lot of the notifications were > being rejected due to that policy. > > I’m not sure what the actual solution is here, but for the short term I told > the client to move to p=none because they are being paid to send these > notifications and the notifications are failing. These kinds of indirect > corporate mail flows seem to be an increasing problem - I saw another report > of the same issue. I’m interested in hearing what the practical and > implementable solutions are here. I brought it up on one forum and the only > suggestion I got was to “add the forwarding systems to SPF.” I said no, > because that’s unworkable. > > It seems to me that until ARC is in widespread use, there will be mail that > is too important to use p=reject for. Yes, in fact, if I’m not mistaken the concept of the “general purpose” domain that’s perpetually p=none came about because of these kind of scenarios. One or more subdomains set aside for such use cases. It might be just a necessity as an intermediate step along this journey. Neil ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
