ARC, from my understanding, can not be accepted as a viable solution for accepting email that were modified (and had their SPF/DKIM broken).
Correct me if I'm wrong, but from what I understood, using ARC, I can craft an email that came from [email protected] - of course ignoring all the SPF/DKIM that @whitehouse.org has implemented, add an ARC signature on top of that saying that "yes, the email originally came from whitehouse.org and SPF/DKIM was not broken at the time", sign this with an ARC-Signature from my h4ck3r domain and all the services that have implemented ARC should accept my email because, hey ! I signed it, you can trust me! 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? Le jeu. 16 juin 2022 à 20:11, Al Iverson via mailop <[email protected]> a écrit : > Jeff, this is really interesting. Thanks for sharing. This answers a > lingering question for me as far as what practical applications there can > be for ARC in a context other than a mailing list. > > Am I getting this right -- the way this would work is that another email > platform would sign/"seal" a current state of the message authentication > into the ARC header and then Microsoft, if it trusts that ARC signer, reads > the ARC results to pass messages that would have perhaps otherwise failed > authentication checks due to forwarding etc. past that point? > > Regards, > Al Iverson > > On Thu, Jun 16, 2022 at 10:05 AM Jeff Dellapina via mailop < > [email protected]> wrote: > >> Folks, >> >> >> >> As email passes thru our network, we make changes to the message. We may >> add items to the header/footer or change links into “protected mode”. >> Doing so breaks Authentication. >> >> >> >> Authenticated Received Chain (ARC). ARC helps preserve authentication >> results *across* intermediaries. >> >> >> >> Learn more about ARC and how we make it work here: >> >> Improving “Defense in Depth” with Trusted ARC Sealers for Microsoft >> Defender for Office 365 - Microsoft Tech Community >> <https://techcommunity.microsoft.com/t5/microsoft-defender-for-office/improving-defense-in-depth-with-trusted-arc-sealers-for/ba-p/3440707> >> >> >> >> >> >> We have used ARC for a while, but this is the first time we rolled it out >> to our 0365 customers. That said… there are some email filtering vendors >> that are not using ARC which breaks authentication. In those cases, we are >> forced to bulk or reject legitimate email sometimes from our own customers >> who use email filtering services. >> >> >> >> >> >> Thanks, >> >> Jeff Dellapina >> >> >> >> Sr. Email Delivery Manager >> >> SAGE Team >> >> >> _______________________________________________ >> mailop mailing list >> [email protected] >> https://list.mailop.org/listinfo/mailop >> > > > -- > > Al Iverson / Deliverability blogging at www.spamresource.com > Subscribe to the weekly newsletter at wombatmail.com/sr.cgi > DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) > _______________________________________________ > mailop mailing list > [email protected] > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
