オーセンティケーテッド・レシーブド・チェーン (Authenticated Received Chain、ARC) は電子メール認証システムである。中間メールサーバ (メーリングリストや転送サービスなど) で、電子メールの本来の認証結果に署名を付加することで認証を実現する。これにより、電子メールのSPFレコードやDKIMレコードが中間サーバ での処理によって無効になってしまう場合でも、受信側のサービスで電子メールを検証できる。
ARCは2019年7月に公開されたRFC 8617において、「実験的 (Experimental)」として定義されている。
IETFからは、ARCはもはや使用されるべきではないと提案されている。ARCは電子メールのレピュテーションに関する問題を解決しなかった。一部の機能はDKIMv2に組み込まれる可能性がある。
概要 DMARCは、送信者のドメインが自らの電子メールをSPFやDKIMで保護していることを示し、これらの認証方式がいずれもパスしなかった場合にメッセージを拒否するなど、受信側サービスにどう対処すべきかを指示する仕組みである。しかし、厳格なDMARCポリシーは、メーリングリストや転送者を経由して送信される正当な電子メールをブロックしてしまう可能性がある。これは、件名タグやフッターの追加などでメッセージが変更されるとDKIM署名が無効になり、またSPFチェックも（転送者がバウンスアドレスを変更しなかった場合は）失敗するか、メッセージ作成者のドメインではなくメーリングリストのドメインと一致してしまうためである（メーリングリストがFrom: ヘッダーフィールドを書き換えない限り）。
ARCは、中間サーバーに元のメッセージの検証結果を署名する方法を提供することで、この問題を解決するために考案された。SPFとDKIMの検証が失敗した場合でも、受信側サービスはARCチェーンを検証することを選択できる。元のメッセージがSPFとDKIMのチェックにパスしており、受信側サービスが信頼する中間者によってのみ変更が加えられたことを示している場合、受信側サービスはその電子メールを受け入れることを選択できる。ARCチェーンの検証は、受信者がARC署名者を信頼している場合にのみ意味を持つ。実際にはARCチェーンは偽造可能であるため、ARC処理は受信者がARC署名者のフィルタリング手法ではなく、その誠実さを信頼している場合に適用される。
実装 ARCは、新たに三つのメールヘッダフィールドを定義している。
ARC-Authentication-Results (略号 AAR) - インスタンス番号 (i) と、SPF、DKIM、DMARCによる検証の結果。 ARC-Seal (略号 AS) - インスタンス番号 (i)、以前のARC-Sealヘッダフィールド (一般に複数) に対するDKIM類似の形式の署名 (「封緘」〔seal〕と呼ぶ)、直前のARCエントリの有効性。 ARC-Message-Signature (略号 AMS) - インスタンス番号 (i) と、メッセージ全体 (ARC-Sealフィールドは除く) に対するDKIM類似の形式の署名。
中間サーバは、次の手順を踏んで改変に署名を付加する。 Authentication-Resultsヘッダフィールドの内容 (改変前に行われたSPF、DKIM検証の結果) を、メッセージの先頭にARC-Authentication-Resultsフィールド (i=1から開始) として追加。 メッセージ (AARを含む) の署名を計算し、メッセージの先頭にARC-Message-Signatureフィールドとして追加。 以前のArc-Sealヘッダフィールド (一般に複数) から封緘を計算し、メッセージの先頭にARC-Sealフィールドとして追加。
受信側は、次の手順を踏んでARCの検証をする。 ARC-Sealヘッダフィールドの連鎖の検証 (抜けているものがなく、いずれのARC-Sealフィールドでも直前の記載内容が有効とされていることなど)。 最新のARC-Message-Signatureヘッダフィールドの検証 (インスタンス番号に基づき最新のものを判別)。
脚注
外部リンク
関連項目 センダー・ポリシー・フレームワーク (SPF) ドメインキー・アイデンティファイド・メール (DKIM) DMARC