How to read and understand the three components of ARC?

The Authenticated Received Chain (ARC) protocol, which includes ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results, is designed to preserve email authentication results when messages are forwarded or go through mailing lists. Here’s how to read and understand these fields:

1. ARC-Seal (AS): This is a cryptographic seal added by each ARC participant. It covers the ARC message signature and the ARC authentication results of the previous hop in the email’s journey. An ARC-Seal field might look like this:

ARC-Seal: i=1; a=rsa-sha256; t=12345; cv=none; 
          d=example.net; s=selector; 
          b=base64string;

In this example, i=1 is the instance number (the hop count), a=rsa-sha256 is the algorithm used, t=12345 is the timestamp, cv=none is the chain validation status, d=example.net is the signing domain, s=selector is the selector of the signing domain, and b=base64string is the actual cryptographic seal.

2. ARC-Message-Signature (AMS): This is a DKIM-like signature added by each ARC participant. It covers the message’s content and most of the header fields, as well as the ARC-Seal and ARC-Authentication-Results of the previous hop. An ARC-Message-Signature field might look like this:

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.net; s=selector;
          h=from:subject:date:message-id:to;
          bh=base64string;
          b=base64string;

In this example, i=1 is the instance number, a=rsa-sha256 is the algorithm used, c=relaxed/relaxed is the canonicalization algorithm, d=example.net is the signing domain, s=selector is the selector of the signing domain, h=from:subject:date:message-id:to are the covered header fields, bh=base64string is the body hash, and b=base64string is the actual signature.

3. ARC-Authentication-Results (AAR): This field records the authentication results for the message at each hop. It’s similar to the Authentication-Results field but is specific to the ARC protocol. An ARC-Authentication-Results field might look like this:

ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: domain of [email protected] designates 2a00:1450:400c:c00::22a as permitted sender) [email protected];
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

In this example, i=1 is the instance number, mx.google.com is the authenticating server, and the rest of the field records the results of SPF and DMARC checks.

By understanding these fields, you can trace the path an email took from the sender to the recipient and verify its authenticity at each hop, which can be useful for diagnosing delivery issues or investigating potential email spoofing or phishing attempts.

What is an example of a situation where DMARC failed, but ARC preserved the email authentication?

Let’s consider a scenario where an email is sent from a mailing list.

1. Alice sends an email to a mailing list ([email protected]) that she and Bob are both subscribed to. Alice’s email server signs the email with DKIM and it passes SPF and DMARC checks at the mailing list server.
2. The mailing list server forwards Alice’s email to all subscribers, including Bob. However, in the process, it modifies the email’s content (e.g., by adding a footer with unsubscribe information), which breaks Alice’s DKIM signature.
3. Bob’s email server receives the forwarded email. It tries to verify Alice’s DKIM signature, but the check fails because the email’s content has been modified. The SPF check also fails because the email now comes from the mailing list server, not Alice’s server. As a result, the DMARC check fails as well, and Bob’s server might mark the email as spam or reject it.
4. However, if the mailing list server supports the ARC protocol, it can add an ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results to the email headers before forwarding it. These fields preserve the authentication results from the mailing list server, which did pass the DKIM, SPF, and DMARC checks.
5. When Bob’s email server receives the email, it can check the ARC fields even if the DMARC check fails. If the ARC check passes, Bob’s server can choose to accept the email despite the failed DMARC check, knowing that the email was legitimately sent by Alice and forwarded by the mailing list.

In this case, the ARC protocol helps to preserve the email’s authenticity despite the modifications made by the mailing list server, improving email deliverability and reducing false positives in spam filtering.

Was this helpful?

YesNo

0 / 0