SRS isn't anything, it was a draft that went nowhere and has no mechanism for authentication. It's basically the same thing as any other ezmlm-style bounce rewriting, with maybe some utility for the relaying server to validate a bounce... but not really.
SPF is only useful for the sender, and there's a limit to the number of include/redirects you can use due to the very low limit on DNS lookups in the standard. DKIM implies ownership that one doesn't want to use for relaying. That all said, DKIM/SPF and by inclusion DMARC are all simple booleans at the end of the day, they tell you one thing and that thing is clear. There is a limit to the utility of that thing, however, ie SPF passing doesn't mean a message isn't spam, you still have to apply some set of rules, reputation, or ML to your mail using those authn features. They are useful in that they allow for better spam/phishing rules. In that sense, ARC isn't that different. It also provides a very limited set of information about the message. It will either tell you nothing changed, which is the same as DKIM, or it will tell you it changed and who changed it. It will also allow you to see the original SPF evaluation. It also lets you know the path the message took. Yes, the result of an ARC pass evaluation is not an indication that a message isn't spam/phishing, you have to have a set of rules, reputation or ML to understand how that affects whether to accept/reject/quarantine that message. Yes, the easiest way to use this is with an allowlist, which is most useful either on the individual or enterprise domain level. At scale, using this information is challenging. I'm sure that challenge is what has made the rollout slower. Brandon On Fri, Jun 17, 2022 at 10:07 AM Paulo Pinto via mailop <[email protected]> wrote: > 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 >
_______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
