tldr; what ARC tries to address is already correctly handled by DKIM/SPF/DMARC if used as designed.
IMHO ARC seems to be a solution to a problem that doesn't exist. The message passes through your network and you make changes to it in the process ? Sign it with DKIM on your edge/"last hop" server, as it should be. After all the message should be DKIM signed once is finished and ready to send, not while it is being written. I confess I didn't read the whole details of the RFC but one thing stroke me: you validate an "ARC sealer" using a DKIM-like mechanism ( public/private key) right ? If so... what's the difference for a pure DKIM signature ? Why add another layer of complexity if that problem was already addressed by another mechanism ( DKIM ) ? And no, SPF is no excuse: that's what "+include:" an "+redirect:", etc, exist for. I can't seem to find any valid reason for a permanent SPF failure: if a server/subnet/whatever may be the origin of mail from a domain, add that server/subnet/whatever to the SPF record. Not that difficult, I think. And redirects ? That's what SRS is for. I may (and that's a real possibility ) be overlooking something obvious about all this and if so please elucidate me, but for now I'm only seeing ARC as a problem we all will have to address, that will be the cause of issues and customer calls/tickets ... and all to solve a problem that simply does not exist. Regards, On Fri, Jun 17, 2022 at 8:20 AM Cyril - ImprovMX via mailop < [email protected]> wrote: > 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 > -- -- Paulo Azevedo
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
