On 2022-06-17 at 09:12 +0200, Cyril - ImprovMX wrote: > Obviously, this can't be it. One solution to this would be to set up > a whitelist of services that you can rely on when you receive an ARC- > Signed email, but this creates a two-way Internet and I prefer mine > neutral, or at least optimistic rather than favoring (yet again) the > big player in opposition to the new one coming to town and being > honest. > > But maybe I missed something on the way ARC works and it does really > ensure that the one signing the received email (and further modifying > it, thus breaking the SPF or DKIM) can be effectively trusted without > a prior white listing?
That's the crux of ARC, and IMHO the reason it still hasn't taken off after all these years. It requires the sealer to be trusted, and there's not a good solution of deciding which entities to trust as signers. The theory is that if someone is a liar, other people (hosts) wouldn't believe them. Surely, ML could learn that certain seals are a bad sign, but it still doesn't help that much on who to trust automatically to override a failing DMARC check. The bit you are missing from Microsoft rollout is that the tenant must: > Add the intermediary’s domain to the ARC trusted sealers list > (Microsoft 365 Defender portal > ARC trusted sealers). So, if the O365 admins said "Yes, we are using h4ck3r-domain.example and blindly trust their DMARC checks", their ARC seal would override the check performed downstream by O365 platform. Otherwise, they would be ignored. Best regards _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
