When you look at email headers, you'll often see a lot of complex-looking information. One set of headers that has become increasingly common is the Authenticated Received Chain, or ARC. ARC is a system designed to preserve email authentication results, like SPF and DKIM, as an email travels through various servers, especially intermediaries like mailing lists or forwarding services. These intermediaries can often break the original authentication, and ARC helps the final recipient's server make a more informed decision about the email's legitimacy. Within the ARC framework, you'll find three distinct headers added at each hop: ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. The ARC-Seal header contains several tags, and the b= tag is one of the most critical.
Understanding the ARC header set
Before we can understand the b= tag, it helps to know what the ARC-Seal header is sealing. Each time an intermediary forwards an email, it adds a 'set' of ARC headers. Each set has an instance number, identified by the i= tag. This creates a chain of custody.
The headers in each set are:
- ARC-Authentication-Results: This header records the authentication results (SPF, DKIM, DMARC) as seen by that specific intermediary server.
- ARC-Message-Signature: This is a DKIM-like signature that covers the message content, including any modifications made by the intermediary (like adding a footer).
- ARC-Seal: This header 'seals' the previous two ARC headers for that instance. It provides a signature that validates the integrity of the ARC headers themselves. This is where the b= tag comes in.
The `b=` tag: The digital signature
The b= tag in an ARC-Seal header contains the cryptographic signature of the seal itself. Think of it like the b= tag in a standard DKIM signature, but instead of signing the email's body and certain headers, it signs the other ARC headers from the same instance.
Specifically, the signature in the b= tag validates the contents of the ARC-Authentication-Results and ARC-Message-Signature headers from the same instance (i.e., with the same i= value). This process ensures that the information recorded by the intermediary has not been tampered with in transit to the next hop or the final recipient.
If this signature is invalid, the entire ARC set for that instance fails validation. The final receiving server will see a result like arc=fail (signature failed). This indicates a break in the chain of trust, and the receiving server will likely disregard the information in those ARC headers.
In short, the b= tag is the linchpin that provides integrity to the Authenticated Received Chain. It's the digital signature that allows a recipient's mail server to trust the authentication results reported by each server in the email's journey. Without a valid b= signature, the ARC-Seal is broken, and the chain of trust is lost.
