> On May 8, 2024, at 3:48 AM, Laura Atkins <la...@wordtothewise.com> wrote: > > > >> On 8 May 2024, at 02:25, Scott Kitterman <skl...@kitterman.com> 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
