ARC (Authenticated Received Chain) is an email authentication mechanism, sort of. The point of ARC is to encapsulate a check of email authentication results and include it in forwarded mail.
If I receive email at an address, then I forward mail to another address, authentication results are difficult for the mail server at the second receiving site to interpret correctly. SPF works on a "last hop" methodology, meaning that a server doing an SPF check can only check the server that just connected to it -- making it incompatible with email forwarding, because email forwarding involves more servers and thus more "hops." A DKIM authentication signature is supposed to be compatible with email forwarding, but there are enough glitches out in the wild -- encoding problems, rewriting headers for forwarding (or adding headers or footer text for mailing lists) that it just doesn't work perfectly 100% of the time. And then the icing on the pain cake is DMARC, where, especially given the use case of mailing lists, knowing that SPF will break and DKIM can break, means that mail from a person at a domain with a restrictive DMARC policy to a mailing list can lead to problems.
Meaning, in my opinion, DMARC and mailing lists effectively became a solved problem.
But then along came ARC -- supposedly to fix this problem (assuming you didn't agree with my take that the problem was already fixed). ARC would let you pass through authentication results from the mail handed off into the mailing list manager's email server and pass it along to recipients of the mailing list, letting their mail server properly evaluate the authentication results of the original submitter's message to the mailing list.
There's a limitation there, though. To use ARC, you have to trust that the server handing you the mail can be trusted. That their authentication results were legitimate and accurate. Attaching trust to the model isn't THAT weird, in that email deliverability and reputation carries a strong trust component already, but in this case of a world widely using ARC, how do the big guys -- the Gmails, Yahoos, and Hotmails -- know which ARC signatures to trust, especially considering so many mailing list are run by hobbyists and at small volume, on custom domains? To me, that made ARC a non-starter.
ARC was, it felt to me, a solution in search of a problem. Mailing lists and email forwarding can't rely on ARC easily because of the trust component -- and they, in my opinion, didn't need to. So, I pretty much ignored any news about ARC, and you'll note that I've never really blogged about it here.
And it clicks for me now. This is it -- this is the use case for ARC -- "ARC helps preserve authentication results across intermediaries," as Microsoft puts it. What this means is that for enterprise email customers who may use multiple email security and anti-spam solutions, and there are a lot of people out there who do this, it'll help address issues with the second solution mis-interpreting authentication results that were correctly measured by the first solution. The edge server, maybe a Proofpoint or Barracuda email security/spam filter, grabs and forwards email on to user end mailboxes hosted by Microsoft's O365. If that Proofpoint or Barracuda solution understands ARC, and can add ARC results to the forwarded email message, O365 can be configure to interpret those ARC results. Meaning that this second step checking service (Microsoft, in this example) will now have accurate authentication results, where previously it had inaccurate results (due to how SPF always works and how DKIM can be fussy).
At one place I worked, the company used Gmail (Google for Business) for email, but put Proofpoint filtering in front of that, for added security. This meant that whenever I would "view source" on an email in my corporate Gmail inbox, the authentication results in the headers would be wrong -- showing the wrong IP, possibly showing the wrong DKIM results, etc. -- because ARC wasn't being used to pass results from Proofpoint to Google. In my case, it made it harder to explain to folks how to report spam, but in the broader sense, it likely made it harder for Google to know whether or not it was allowing a legitimate message through its filters. ARC would help to fix that.
If the big email security and anti-spam solution providers implement ARC, and add a configurable setting to be able to trust ARC results from a certain other provider, a problem is solved. Email authentication results get more accurate in the corporate email realm. And that makes email safer and more secure, and that's a good thing.
Thanks, Microsoft, for helping me see the light, and understand the value of ARC.
ARC (Authenticated Received Chain) is an email authentication mechanism, sort of. The point of ARC is to encapsulate a check of email authentication results and include it in forwarded mail.
If I receive email at an address, then I forward mail to another address, authentication results are difficult for the mail server at the second receiving site to interpret correctly. SPF works on a "last hop" methodology, meaning that a server doing an SPF check can only check the server that just connected to it -- making it incompatible with email forwarding, because email forwarding involves more servers and thus more "hops." A DKIM authentication signature is supposed to be compatible with email forwarding, but there are enough glitches out in the wild -- encoding problems, rewriting headers for forwarding (or adding headers or footer text for mailing lists) that it just doesn't work perfectly 100% of the time. And then the icing on the pain cake is DMARC, where, especially given the use case of mailing lists, knowing that SPF will break and DKIM can break, means that mail from a person at a domain with a restrictive DMARC policy to a mailing list can lead to problems.
This is not a new problem. Back in 2014-2015 I was answering complaints about DMARC's impact to mailing lists and email forwarding. It takes only a small bit of work to rewrite headers as needed for mail forwarding, and email discussion lists only needed some easy and similar modifications to keep mail flowing successfully. They deliver mail to end users; allow them to take control of authentication and reputation by authentication a message as being from the mailing list, instead of the person who posted to the mailing list. Yahoo and Google both led the way on this front in 2014, and eventually, pretty much everybody else caught up.
Meaning, in my opinion, DMARC and mailing lists effectively became a solved problem.
But then along came ARC -- supposedly to fix this problem (assuming you didn't agree with my take that the problem was already fixed). ARC would let you pass through authentication results from the mail handed off into the mailing list manager's email server and pass it along to recipients of the mailing list, letting their mail server properly evaluate the authentication results of the original submitter's message to the mailing list.
There's a limitation there, though. To use ARC, you have to trust that the server handing you the mail can be trusted. That their authentication results were legitimate and accurate. Attaching trust to the model isn't THAT weird, in that email deliverability and reputation carries a strong trust component already, but in this case of a world widely using ARC, how do the big guys -- the Gmails, Yahoos, and Hotmails -- know which ARC signatures to trust, especially considering so many mailing list are run by hobbyists and at small volume, on custom domains? To me, that made ARC a non-starter.
ARC was, it felt to me, a solution in search of a problem. Mailing lists and email forwarding can't rely on ARC easily because of the trust component -- and they, in my opinion, didn't need to. So, I pretty much ignored any news about ARC, and you'll note that I've never really blogged about it here.
Until we fast forward to modern day. A couple of weeks ago, a representative from Microsoft shared with the Mailop list that Microsoft would now generate and incorporate ARC results into mail flowing inbound through Office 365, Microsoft's corporate email solution.
And it clicks for me now. This is it -- this is the use case for ARC -- "ARC helps preserve authentication results across intermediaries," as Microsoft puts it. What this means is that for enterprise email customers who may use multiple email security and anti-spam solutions, and there are a lot of people out there who do this, it'll help address issues with the second solution mis-interpreting authentication results that were correctly measured by the first solution. The edge server, maybe a Proofpoint or Barracuda email security/spam filter, grabs and forwards email on to user end mailboxes hosted by Microsoft's O365. If that Proofpoint or Barracuda solution understands ARC, and can add ARC results to the forwarded email message, O365 can be configure to interpret those ARC results. Meaning that this second step checking service (Microsoft, in this example) will now have accurate authentication results, where previously it had inaccurate results (due to how SPF always works and how DKIM can be fussy).
At one place I worked, the company used Gmail (Google for Business) for email, but put Proofpoint filtering in front of that, for added security. This meant that whenever I would "view source" on an email in my corporate Gmail inbox, the authentication results in the headers would be wrong -- showing the wrong IP, possibly showing the wrong DKIM results, etc. -- because ARC wasn't being used to pass results from Proofpoint to Google. In my case, it made it harder to explain to folks how to report spam, but in the broader sense, it likely made it harder for Google to know whether or not it was allowing a legitimate message through its filters. ARC would help to fix that.
If the big email security and anti-spam solution providers implement ARC, and add a configurable setting to be able to trust ARC results from a certain other provider, a problem is solved. Email authentication results get more accurate in the corporate email realm. And that makes email safer and more secure, and that's a good thing.
Thanks, Microsoft, for helping me see the light, and understand the value of ARC.
Want to learn more about Microsoft and ARC? Read Improving “Defense in Depth” with Trusted ARC Sealers for Microsoft Defender for Office 365.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.