Understanding the Authenticated Received Chain (ARC).

In this post, we will understand what is ARC and why it is used.

What is ARC? 

ARC is the authenticated received chain added in the email header by the intermediaries.

Why ARC?

Authenticated Received Chain (ARC) solves the issues that arise in email authentication of indirect mail flow.

What is Indirect mail flow?

Indirect mail flow is when the email is not directly received from the sender system, and they are passed through the intermediaries before they are delivered to the recipients. 

Eg: mails received from a mailing list, or account forwarding.

  • Intermediary sends the message from a new IP address, causing SPF to fail
  • Intermediary changes the message contents, causing DKIM to fail

Solution: ARC was devised to solve this problem by giving intermediate servers a way to sign the original message's validation results. Even if the SPF and DKIM validation fails, the receiving service can choose to validate the ARC chain.

What are the different parts of the ARC header?

ARC has three parts.

  • ARC-seal: Contains an Instance number (i=) tag, signing domain in (d=) and the validation result of the prior ARC in (cv=) tag if found andy, and signature in (b=) tag.
  • ARC-Message-Signature: Contains an instance number (i=) and a DKIM-like signature (b=) and email body hash (bh=) value calculated of the entire message except for the ARC-Seal headers, values used in the hash computation are included in the (h=) tag.
  • ARC-Authentication-Results: Contains authentication results of SPF, DKIM, DMARC, and previously signed ARC.
ARC iteration is recorded in the (i=) tag, each intermediary may add one set of ARC authentication, so there could be multiple Authentication chains in the message header.

Now let's analyze the Authentication chain from a message header that involves the forwarding.

In the test message which I sent from Office 365 to my Gmail account and then forwarded to my Zoho email account, I found 3 sets of Authentication chains (ARC).

The below-mentioned Authentication chain is added by the 1st sender (d=microsoft.com), can be seen on the ARC-Seal and it is the first iteration of the authentication chain as can be seen in the (i=1) tag.

ARC-Seal:i=1;a=rsa-sha256;s=arcselector9901;d=microsoft.com;cv=none; 
b=hHKv1LH/q7QPDa9zHQkK7AsDZpH527MaIpo6cdQbnsxr6NWp9ywYAPruYV78nEgl

ARC-Message-Signature:i=1;a=rsa-sha256;c=relaxed/relaxed;d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version..;
bh=JLqRj4hQ3j4my5ikpnsfqaeCAL5Ne00fEMqbrTD4h/4=;
b=BD5niXEk/wUbcitOLIbm9Kec7nYro0e2lbK+3aQOdlxeIPrMdRNXttekUbcV/

ARC-Authentication-Results: i=1; mx.microsoft.com 1; 
spf=pass smtp.mailfrom=lab365.in; 
dmarc=pass action=none header.from=lab365.in;
dkim=pass header.d=lab365.in;
arc=none

Above ARC-authentication-results are added by the 1st sender MTA (mx.microsoft.com), as we can see that SPF, DKIM, and DMARC authentication is added and the cv=none and arc=none.

The (cv= and arc=) tag could have three values
  • none    - No ARC chain to validate
  • pass     - ARC chain validation passed
  • fail      - ARC chain validation failed
Below is another set of Authentication chains from google, where it says i=2 and in the ARC Seal chain validation cv=pass. 

ARC-Seal: i=2; a=rsa-sha256; t=1640770738; cv=pass; d=google.com; 
s=arc-20160816; 
b=aygLwXdcqgcZtrtMEuqeytWxoiLDaym+Pw80j2czWjCLs1KxzNHerpc63DqjL5YcGY

ARC-Message-Signature: i=2;a=rsa-sha256;c=relaxed/relaxed;d=google.com;
 s=arc-20160816; h=mime-version:content-language:accept-language....; 
b=EJbx2vp+QM/n+eRHI802OkM6wgqurzmpChmBVGEIyOw3T7dm8GnN8W5E4hPBbGehxS 

ARC-Authentication-Results: i=2; mx.google.com;
dkim=pass header.i=@lab365.in header.s=selector2 header.b=pCmfPmVw;
spf=pass (google.com: domain of labadmin@lab365.in designates 
2a01:111:f400:fea4::61f as permitted sender) smtp.mailfrom=labadmin@lab365.in;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=lab365.in

arc=pass (i=1 
spf=pass spfdomain=lab365.in 
dkim=pass dkdomain=lab365.in 
dmarc=pass fromdomain=lab365.in);

In the above ARC Authentication results, we can see that the google MTA checked the email authentication (SPF/DKIM/DMARC) along with the ARC validation which was passed arc=pass, and the pass results are included in the authentication chain.

Now let's see the final iteration (i=3) from zoho.com

ARC-Seal: i=3; a=rsa-sha256; t=1640770739; cv=pass; d=zohomail.com; 
s=zohoarc; 
b=aT7DKuzcGg5Gi1vT/M1EoehU0ehCFT8RxaX3XXLCFAU9Qgtqhexqw+UGWnsMtIm/

ARC-Message-Signature:i=3;a=rsa-sha256;c=relaxed/relaxed;d=zohomail.com; 
s=zohoarc; t=1640770739; 
h=Content-Type:Date:From:MIME-Version:Message-ID:Subject:To;
bh=JLqRj4hQ3j4my5ikpnsfqaeCAL5Ne00fEMqbrTD4h/4=;
b=XHq/OSi0+YHUBPYZ38XRKZD481b91YY+J8srIOOaSc9gCRTXmWkiSqaamICWb5KoM

ARC-Authentication-Results: i=3; mx.zohomail.com;
dkim=pass;
spf=pass (zohomail.com: domain of _spf.google.com designates 
209.85.160.178 as permitted sender) 
smtp.mailfrom=sunilkms+caf_=sunilkms=zoho.com@gmail.com;
dmarc=pass header.from=<labadmin@lab365.in> (p=quarantine dis=none)
arc=pass (i=2 dmarc=pass fromdomain=lab365.in);

In the above chain, we can see that email authentication for (spf/dkim/dmarc) is passed. 

*** SPF would usually fail in the forwarding scenarios, but google rewrote the smtp.mailfrom address also called the P1 address, which helped to pass the SPF in this case, similar action is also done by Microsoft which is called Sender Rewriting Scheme (SRS), note that this address is different from the header.from the address which user sees as mail received from that is called the p2 address and will remain unchanged.

Also, note that header.from is the address based on which the DMARC alignment is checked. 

We can see that Zoho also validated the authentication chain which was passed, in this case even if the SPF and DKIM would have failed the email would successfully be delivered in the inbox folder.

This completes my post ARC, feel free to leave the comments and your feedback.

Comments

Post a Comment