Microsoft’s Increasing Support for ARC

In 2019, Microsoft included ARC support on their Microsoft 365 Roadmap, stating that “(ARC) is now enabled for Office 365 hosted mailboxes.” But at the time, it was only being used for Microsoft senders, or between Office 365 tenants. In 2022, they expanded this to include third party ARC sealers configured on a per-tenant basis.

Microsoft diagram, email message flow using ARC with Office 365

Diagram courtesy Microsoft Defender for Office 365 Blog

The original announcement described the benefits ARC could bring to the users of Office 365 who receive email that has been processed by intermediaries. These third parties might be outsourced help desk operators, or compliance and archiving solutions, or email security and anti-abuse providers. However the announcement ended with the caution that, at that time, ARC was only being evaluated for messages sent between Microsoft systems and/or customers, and that they “plan to add support for third party signers in the future.”

In June 2022, an article was published on the Microsoft Defender for Office 365 Blog that described ARC and how Office 365 tenants would be able to use a new “Trusted ARC Sealers” feature to identify intermediaries that they were using, whose authentication results – recorded in their ARC seals – should be used if they validated. An associated article (Make a list of trusted ARC Senders to trust legitimate indirect mailflows) described how Microsoft Defender 365 administrators could create a list of Trusted ARC Sealers.

This was a long-awaited development, though introduced rather quietly, and Microsoft deserves credit for helping to advance the utility of ARC for enterprise email users. It would be interesting to see what impact it has had for Office 365 tenants who have populated their Trusted ARC Sealers list since the announcement.

Microsoft “enabled” ARC in Office 365

On October 24th an update was published on the Microsoft 365 Roadmap indicating that “Authenticated Received Chain (ARC) is now enabled for Office 365 hosted mailboxes.”

The rather terse update describes the benefits ARC could bring to the users of Office 365 who receive email that has been handled by intermediaries. But it ends with text that may indicate that, for now, it is only being evaluated for messages sent between Microsoft systems and/or customers. “Initially ARC will only be utilized to verify authentication results within Office 365, but plan to add support for third party signers in the future.”

This link should bring up the entry on the Microsoft 365 Roadmap.

RFC 8617 “The Authenticated Received Chain” Published

The Authenticated Received Chain, or ARC, was published by the IETF RFC Editor on Tuesday, July 9th, 2019 as RFC 8617. The general information page for RFC 8617 can be found here, but there are direct links to HTML, PDF, and text versions available. ARC has been published under the IETF’s Experimental status, which is explained in this section of RFC 2026. This reflects that fact that some fine-tuning is expected after Internet senders and receivers gain experience with the protocol after deploying it widely, and seeing what the operational impacts are.

DMARC.org first publicly announced the ARC protocol in October 2015, and it became an official work item of the IETF DMARC Working Group in June 2016. The specification went to “working group last call” in October 2018, but attention shifted to several related areas that needed clarification. This led to revisions to the header field for authentication status (RFC 8601), and updating SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) to better handle internationalized domain names (RFC 8616).

Version 18 of ARC Specification Published

On October 2nd, the IETF’s DMARC Working Group published version 18 of the ARC specification document, incorporating the changes suggested during the Working Group Last Call (WGLC).  There are many small language changes to clarify concepts or bring usage in line with other IETF documents, such as Email Address Internationalization (EAI).

You can review the changes between the pre- and post-WGLC versions using this link.

Working Group Completes Last Call For ARC Specification

The DMARC Working Group has completed Last Call for the ARC specification. This means that when the final consensus changes are incorporated, the document will be submitted for approval and publication by the IETF. It is possible that the specification might be published before the next IETF meeting in November, though perhaps more likely between then and the following meeting in March 2019.

The ARC specification has been under development by the Internet Engineering Task Force’s (IETF) DMARC Working Group since roughly June 2016. In July, just over two years later, the Working Group reached a milestone known as Working Group Last Call (WGLC). During Last Call the members of the group determine if consensus has been reached on the content of the document in question. If so, any final changes are made to the document and it is submitted to one or more IETF officials known as Area Directors. Upon review they may ask questions or make suggestions, and when satisfied, the document is approved for publication.

The ARC specification grew out of work begun by a group known as OAR in the summer of 2014. OAR refers to a proposed email header named Original Authentication Results, the subject of a draft proposal published in 2012.

New ARC Implementations at IETF 99 Hackathon

An ARC table was organized at the weekend hackathon held before the IETF 99 meeting in Prague this week. ARC is an official work item of the IETF DMARC Working Group, and will be discussed during the working group meeting Thursday morning.

Participants from two different vendors worked on new implementations of ARC, compatible with their software stacks. By the end of the weekend, one of these implementations was able to validated multiple-hop ARC chains, which is perhaps the hardest part of any implementation. And a participant from a third vendor indicated they have made significant progress in developing their own ARC implementation prior to the weekend.

If you compare this to all proprietary and open source implementations known before the hackathon, it will represent a 60% increase in the number of ARC implementations when they are completed. In addition to the implementations mentioned, the weekend included more interoperability testing, bug hunting, patch generation, and pull requests.

Many thanks to all the participants at the hackathon, whether they were in the room or working remotely!

ARC Packages And Modules Available

Several packages and libraries implementing ARC are now available, and are linked from our new Resources page. Mailbox providers and maintainers of mailing list manager (MLM) software can use these components to start adding ARC functionality to their products and services today.

For those creating their own ARC modules and products, the new ARC test suite from ValiMail is an ideal validation tool – and completely free to use. The test suite has been used to validate the dkimpy package with an Python library and command line tools, and the OpenARC milter is currently being validated.

Or if you just want a turnkey solution, add ARC to your platform by using the fully supported MailerQ commercial MTA from Copernica.

Patches to add ARC functions to the Mailman MLM should be available soon, and ARC should be integrated into the Sympa MLM by mid-year.

 

Two ARC Implementations Tested At Interoperability Event

On February 19th representatives from AOL (NYSE:VZ)  and Google (NASDAQ:GOOG) successfully tested the first two implementations of the ARC protocol at an interoperability event. LinkedIn (NYSE:LNKD) hosted the in-person, all-day event at their San Francisco offices and facilitated the testing. Also participating were representatives from Cloudmark, Comcast (NASDAQ:CMCSA), DMARC.org, the Trusted Domain Project, and Message Systems/SparkPost.

“We set an aggressive target for testing when we announced the ARC protocol in October. AOL and Google did an outstanding job developing implementations and preparing test systems in time for this event,” said Steven M. Jones, executive director of DMARC.org. ARC addresses a small but important class of messages, like mailing lists and forwarding services, that are impacted when a sending domain has a strong DMARC policy. Jones added, “I think ARC will allow more consumer mailbox providers and other domain operators to join AOL and Yahoo (NASDAQ:YHOO) in adopting such policies in order to better protect their users and their users’ correspondents from fraudulent messages.”

More implementations of ARC are under development, including an open source package that could be used to add ARC capabilities to existing email services. Additional interoperability testing events will be held between now and mid-year. For more information please visit the ARC protocol website at http://arc-spec.org.