[peanut-walrus]

The attack works for spoofing email from domains that have DMARC configured with reject policy against receiving servers that validate DMARC and act correctly according to policy. Only requirement is that the domain the attacker is spoofing is using O365.

This is not a UX problem. This is a Microsoft problem.

[tric]

> Only requirement is that the domain the attacker is spoofing is using O365.

This is not true. The paper mentions multiple service providers using more relaxed validation.

Table 3, section 5 in the paper shows which policies need to be in place on the domain they are piggy-backing on.

They reference Postfix:

"Additionally, we note that mailing list software such as Listserv and Mailman require a backend MTA. In our experiments we used Postfix with DMARC turned on, a configuration which follows good security practice. However, in practice many organizations might not use this configuration because many MTAs (including Postfix) do not enforce DMARC by default. In these cases, the attacker can spoof email from any target domain, regard- less of its DMARC policy, much like the attack against Gaggle."

I read this to mean that if you actually enable DMARC in Postfix, piggy-backing on another domain's policies results in rejection.

No mention of results for receiving at ProofPoint, Mimecast, Trellix, or Cisco's email appliance.

> This is not a UX problem.

They are demonstrating a problem with managed providers, and their opinionated configuration. You give up a lot of control as an admin when you use 365 as your front-end. This further proves that.

[peanut-walrus]

Yes, they mention that Fastmail, GMX, Inbox.lv, and Pobox also allow per-user DMARC overrides, including overriding reject policy. But Microsoft is the only one of these using MFEF forwarding which enables the attack to be successful.

I suppose similar attack to the one in 5.1 would work against Fastmail, but the victim would be able to see the original envelope from to detect that the mail is spoofed.