The real quirk is that Microsoft is using ARC for something for which it was never intended. I am open to fixing ARC to support what they want to do, but their current implementation only exposes how easily an attacker can misuse ARC to "authenticate" his own stuff.
If ARC is to be used to add extra authentication at origination, it would need to include the other authentication mechanisms: - User credentials (Web interface, MAPI, ActiveSync, Exchange Web Services, Authenticated SMTP, API.) - Sever-to-server credentials - Trusted IP - Known Client (probably supplemented by one of the above) for handoff from an originating organization to its outbound filtering services In the absence of those options, Microsoft seems willing to make up phony authentication results, just like a spammer would. DF On Sat, Mar 25, 2023 at 8:45 AM Mark Alley <mark.alley= 40tekmarc....@dmarc.ietf.org> wrote: > There have been noticeable quirks with the method that Microsoft has > attempted ARC implementation (regarding outbound sealing). > > For enterprise/business tenants, these customers have full control over > their mail routing (such as, say, sending outbound mail through a third > party spam filter or another service). > > With this scenario, it is a common configuration to remove Office 365's > SPF include mechanism from a domain's SPF record; since O365 is no longer > directly sending mail to external receivers, the filter is now the last hop. > Additionally, as is common with this configuration, DKIM signing will also > be done at the edge with (not on office 365). > > One can start to see the issue with this scenario. The Microsoft ARC set > added here will fail immediately upon application for these customers (and > there are an extremely large amount of tenants with this configuration), > and thus preventing further additions and any usefulness to the ARC by > receivers down the line (such as google) due to its immediate invalidity. > > The argument can be made to simply, "keep O365 in a domain's SPF record", > to fix the ARC authentication in this scenario, but this is not a desired > configuration given that it is currently possible to create SPF aligned > mail from any Office 365 tenant using any domain desired (Outside of the > jurisdiction of the actual domain's tenant). > > You don't see this issue with many other sealers currently because this is > only possible at the moment (as far as I know) with ARC sealers that give > complete control over a domain's egress mail routing, DNS, *and* also seal > ARC on egress mail. For example, this is not a problem for Zohomail, or > Microsoft consumer domains (Hotmail, MSN, live, outlook, etc.), who also > seal ARC on egress mail, because the customer does not control the domain > being sent from. There is no opportunity for this condition to occur. > > Not to detract from their efforts towards its use, as it *does* work as > intended in expected inbound scenarios as-is currently in O365, but there > should definitely be more consideration given by ARC sealers as to when an > ARC set is applied. Possibly by giving sealing condition capabilities to > the customer? > > - Mark Alley > > > > > > On Fri, Mar 24, 2023, 6:18 PM Seth Blank <s...@sethblank.com> wrote: > >> Microsoft is using ARC quite heavily, and has reported on this list and >> at M3AAWG of the impact it makes >> >> Microsoft even has on their public roadmap that tools are being built for >> their customers to enable per-customer sealers that they choose to trust: >> https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=dmarc >> >> On Fri, Mar 24, 2023 at 5:06 AM Steven M Jones <s...@crash.com> wrote: >> >>> On 3/24/23 3:48 AM, Douglas Foster wrote: >>> > >>> > Do we know if any entity other than Google is successfully using ARC >>> > as an evaluation tool? >>> >>> >>> FWIW: In late 2021 a "German company" reported that it was able to >>> "recover" about 10% of messages that had failed other authentication >>> checks by validating ARC. >>> >>> --S. >>> >>> >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc >>> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
