The solution is to eliminate the forwarding step. There are many good reasons why organizations should not allow forwarding to their personal email accounts. Among other reasons, given that employees are missing these alarms, it is likely that they are losing other messages also.
But for the business that insists on doing so, the better solution is to register that final destination account for the alarm subscription. The problem in this case is that the person harmed by domain impersonation will not be the vendor and may not be the foolish client The vendor has little incentive to stand his ground if it means losing a client. Security always creates inconvenience. On Wed, May 8, 2024, 6: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. > > laura > > -- > The Delivery Expert > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Delivery hints and commentary: http://wordtothewise.com/blog > > > > > > > _______________________________________________ > dmarc mailing list -- dmarc@ietf.org > To unsubscribe send an email to dmarc-le...@ietf.org >
_______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
