[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
[dmarc-ietf] Re: New attack leveraging DMARC None
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. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: New attack leveraging DMARC None
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 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. > > 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
[dmarc-ietf] Re: New attack leveraging DMARC None
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. I've seen similar flows for forwarding of mail that customers send to email addresses that then send to ticketing systems which also check email authentication with Spamassassin. They were accommodated for by exempting said traffic from intrusive message modifications to preserve DKIM/SMIME/PGP, etc. To your point, until most corporate email security filters (and everyone else) seal ARC, workarounds like this are unfortunately necessary. - Mark Alley On Wed, May 8, 2024, 5: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. > > 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
[dmarc-ietf] Re: New attack leveraging DMARC None
> 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. 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-ietf] Re: New attack leveraging DMARC None
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. R's, John ___ 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 Tue, May 7, 2024 at 9:27 PM 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. > > Scott K > This reflects one concern that came to mind fairly quickly. When we originally came up with DMARC it was intended for use by domains sending transactional mail and which did not have individual users or very limited individual users. There has been a certain amount of coercion by some large mailbox providers to incentivize email authentication, including DMARC. Publishing P=none is one way of meeting those requirements. These attacks and the recommended response by the FBI put domains with individual users in a difficult position. One might say this is an operational issue and leave it at that. This doesn't strike me as right but I'm not sure what the working group might reasonably do/say in DMARCbis about an operational issue.. Michael Hammer ___ 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 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. Scott K ___ 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 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 ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
