ARC (Authenticated Received Chain)

DMARC
2023.10.19
この記事は約10分で読めます。

ARC（Authenticated Received Chain）は、電子メール認証プロトコルの一つで、DMARCの転送時の認証問題を解決するために設計されました。メールが複数のサービスを経由する場合に認証の結果を維持し、最終的な受信者が元の送信者の正当性を確認するのを助けます。これにより、DMARCポリシーに基づく誤ったリジェクトを防ぐことができます。本記事ではARCに関して、分かりやすく詳細に解説します。

ARCが導入された背景と目的

背景

  1. Eメール認証の進化: Eメール認証の技術、特にSPF (Sender Policy Framework) とDKIM (DomainKeys Identified Mail) が広まるにつれて、Eメールの送信者が示されている通りの正当なエンティティであることを受信者が確認できるようになりました。これにより、フィッシング攻撃やスパムの増加を抑制することが可能となりました。
  2. メーリングリストやフォワーディング: しかし、メーリングリストやEメール転送サービスなどの中継エージェントがEメールを処理する際、そのEメールのヘッダーや本文が変更されることがよくあります。このような変更は、DKIM署名の無効化やSPFの検証の失敗といった認証の失敗を引き起こす可能性があります。
  3. 認証の矛盾: 従って、あるEメールが認証に成功する場所と失敗する場所が存在する可能性があり、これはEメールの配信信頼性に大きな問題をもたらしていました。

目的

  1. 認証結果の保存: ARCの主な目的は、Eメールが中継や転送される過程で、認証の履歴や結果を追跡・保存することです。これにより、Eメールの最終的な受信者は、前のホップでの認証結果を評価することができ、そのEメールの信頼性を判断する材料とすることができます。
  2. 配信性の向上: ARCを採用することで、メーリングリストやフォワーダーなどのサービスを使用する正当なEメールの配信が拒否されるリスクが減少します。このような中継エージェントがEメールの内容を変更しても、ARCはオリジナルの認証状態を最終的な受信者に伝えることができるので、誤って正当なEメールがブロックされるリスクを減少させます。
  3. 認証の透明性: ARCはEメールの認証プロセスの透明性を向上させることを目指しています。それは、受信者がEメールがどのような経路で配信され、その過程でどのような認証チェックが行われたのかを知ることができるようにするためです。

結論として、ARCはEメールの中継や転送の現実に対応するためのソリューションとして設計され、現代の複雑なEメールエコシステムでの認証の問題を解決するための重要なステップとなっています。

ARCの動作

ARCは、Eメールが中継または転送される過程で、認証の履歴や結果を追跡するためのフレームワークを提供します。中継や転送を行うエージェントがEメールの内容やヘッダを変更すると、SPFやDKIMのような認証手段の結果が失敗する可能性があります。ARCはこの問題を解決するために設計されています。

ARCの基本的な動作:

  1. 初期認証: Eメールが最初に受信されたとき、受信サーバは通常どおりSPF, DKIM, DMARCなどの認証チェックを行います。
  2. ARCヘッダーの追加: 認証の結果を元に、以下の3つのARCヘッダーがEメールに追加されます。
    • ARC-Authentication-Results (AAR): このヘッダーは、前のホップでの認証結果を示します。
    • ARC-Message-Signature (AMS): 現在のEメールの内容と一部のヘッダーに対する署名です。
    • ARC-Seal (AS): 他のARCヘッダーの完全性と順序を保証する署名を含むヘッダー。
  3. Eメールの中継: Eメールが中継エージェントやフォワーダーを経由する場合、Eメールの内容やヘッダーが変更される可能性があります。
  4. 次のホップでの処理: その後の中継エージェントも、Eメールを受信するときに認証チェックを行い、新しいARCヘッダーセットを追加します。これにより、認証の履歴がチェーンとしてEメールに添付されるようになります。
  5. 最終受信者での評価: Eメールの最終的な受信者（またはそのメールサーバ）は、ARCヘッダーのチェーンを評価することで、Eメールがオリジナルの送信者からのものであるかどうか、また中継エージェントがどのような操作を行ったかを判断することができます。

このプロセス全体を通じて、ARCはEメールの認証結果を保持し、変更されたEメールの内容でもオリジナルの認証状態を最終的な受信者に伝えることができます。これにより、Eメールの信頼性と配信性が向上します。

ARCの主要なヘッダー

ARC (Authenticated Received Chain) は、メールの中継や転送を経る過程での認証結果を追跡するための仕組みで、これを実現するために特定のヘッダーをメールに追加します。ARCが使用する主要なヘッダーについて詳しく説明します。

1. ARC-Authentication-Results (AAR)

このヘッダーは、前のホップ（前のサーバやエージェント）での認証結果を示します。具体的には、SPFやDKIM、DMARCなどの認証手段の結果が含まれます。これにより、次のホップのサーバやエージェントは、前のホップでの認証結果を確認できます。

例:

ARC-Authentication-Results: i=1; mx.example.com; spf=pass smtp.mailfrom=example.net; dkim=pass header.i=@example.net; dmarc=pass header.from=example.net

2. ARC-Message-Signature (AMS)

このヘッダーは、現在のメールの内容と一部のヘッダーに対するDKIMスタイルの署名を示します。この署名は、メールが前のホップでの状態と一致しているかを確認するためのものです。

例:

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector; t=1234567890; bh=hash-of-body; h=header-list; b=signature-data;

3. ARC-Seal (AS)

このヘッダーは、他のARCヘッダーの完全性と順序を保証する署名を含むものです。もしメールが途中で改ざんされたり、ARCヘッダーが不正に追加/削除された場合、この署名によってそれを検出できます。

例:

ARC-Seal: i=1; a=rsa-sha256; t=1234567890; cv=none; d=example.com; s=selector; b=signature-data;

これらのヘッダーは、メールがさまざまなサーバやエージェントを経由して転送される際に、それぞれが追加するものであり、メールの最終的な受信者はこれらのヘッダーを使用してメールの認証結果のチェーンを確認することができます。このチェーンを通じて、受信者はメールが認証を経て中継されてきたことを確認し、その信頼性を判断する材料とすることができます。

ARCの利点

1. 中継や転送の認証情報の保持:

  • ARCは、Eメールが中継や転送される過程での認証結果を追跡する仕組みを提供します。これにより、元の送信者の認証情報が転送や中継を通じても保持され、受信者が信頼性を判断する際の材料となります。

2. メーリングリストや転送の問題の緩和:

  • メーリングリストや転送サービスは、Eメールの内容やヘッダーを変更することがよくあります。このような変更は、DKIMの署名の無効化やSPFの検証の失敗を引き起こす可能性があります。ARCは、これらのサービスを使用する正当なEメールが誤ってブロックされるリスクを減少させます。

3. Eメールの信頼性向上:

  • ARCの存在により、最終的なEメール受信者は、メールが正当な中継経路を経て送信されたことを確認できます。これにより、Eメールの配信信頼性と配信率が向上します。

4. 認証の透明性と追跡:

  • ARCは、Eメールの認証プロセスの透明性を向上させます。受信者は、Eメールがどのような経路で送信され、その過程でどのような認証チェックが行われたかを知ることができるようになります。

5. 不正な変更の検出:

  • ARC-Sealヘッダーにより、ARCヘッダーが不正に変更された場合や、不正に追加/削除された場合を検出することが可能です。これにより、Eメールの改ざんを検出し、不正な行為を防ぐことができます。

6. Eメールエコシステムの一貫性向上:

  • さまざまなEメールサービスプロバイダ、中継エージェント、メーリングリストオペレーターなどがARCを採用することで、全体としてのEメールエコシステムの一貫性と信頼性が向上します。

総じて、ARCは現代の複雑なEメールエコシステムにおける認証の問題を解決するための重要な技術であり、Eメールの信頼性と配信性を向上させるための鍵となっています。

ARCの制約

ARC (Authenticated Received Chain) は多くの利点を持っていますが、いくつかの制約や考慮すべき側面も存在します。以下に、ARCの主な制約について詳しく説明します。

1. 普及率の問題:

  • ARCが効果を最大限発揮するためには、多くのメールサーバやサービスプロバイダがARCを採用し、正しく実装する必要があります。一部のエンティティのみがARCを実装している場合、その効果は限定的となり得ます。

2. 実装の複雑さ:

  • ARCの実装と維持は比較的複雑であり、メールインフラの設定や管理を行う技術者の知識と経験を必要とします。

3. パフォーマンスへの影響:

  • ARCの署名や検証処理は、メールサーバのリソースを消費します。大量のメールを処理する場合、パフォーマンスの低下が考えられるため、適切なサーバの設定やリソースの調整が必要となる場合があります。

4. 信頼性の誤解:

  • ARCは認証情報の「連鎖」を提供しますが、それが必ずしもメールの内容やその送信者の意図を信頼できるということを意味するわけではありません。ARCの情報を過度に信頼することなく、他の認証手段やフィルタリング技術と併用することが重要です。

5. 完全な保護の欠如:

  • ARCは中継や転送時の認証情報の追跡を助けますが、すべての種類のメール関連の問題や脅威を解決するわけではありません。例えば、初めから偽装されたメールやマルウェアを含むメールに対しては直接的な保護を提供しないことがあります。

6. 既存の認証システムとの整合性:

  • ARCを適切に実装し運用するためには、既存のSPF, DKIM, DMARCなどの認証システムとの整合性を保つ必要があります。これにより、設定の複雑さが増す可能性があります。

ARCはEメール認証の課題に対する有望な解決策の一つとして位置づけられていますが、上記の制約を考慮し、適切な実装と運用が求められます。

ARC実装の検討

ARC (Authenticated Received Chain) の実装を検討する際には、以下のステップや考慮点を参照してください。

1. ニーズの確認:

  • まず、ARCの実装が自分たちの組織やシステムにとって必要かどうかを検討します。特に、メーリングリストを運用している、または大量の転送メールを処理している場合、ARCの実装を検討する価値があります。

2. 既存のEメールセキュリティの確認:

  • SPF, DKIM, DMARCといった既存のEメール認証の仕組みが正しく設定されているか確認します。ARCはこれらの技術と連携して動作するため、基本的な認証設定が重要です。

3. リソースの評価:

  • ARCの実装には、技術的リソース（サーバ容量、ネットワーク容量等）と人的リソース（技術者のスキルや知識）が必要です。十分なリソースを有しているかを事前に評価します。

4. ARC対応のソフトウェア/サービスの選定:

  • 既存のメールサーバソフトウェアやEメールセキュリティサービスがARCに対応しているかを確認します。非対応の場合、ARCをサポートするソフトウェアやサービスにアップグレードする必要があります。

5. テスト環境の構築:

  • 新しい技術を本番環境で導入する前に、テスト環境でARCの動作を確認します。これにより、予期しない問題やエラーを未然に防ぐことができます。

6. 実装:

  • テスト環境での検証が完了したら、本番環境にARCを実装します。

7. モニタリングと調整:

  • ARCの実装後は、その動作を定期的にモニタリングし、必要に応じて調整を行います。特に、メールの配信率や認証結果の変動を確認することが重要です。

8. ドキュメントの作成と保守:

  • ARCの設定、運用手順、トラブルシューティングのガイドラインなど、関連ドキュメントを整備し、スタッフ間で共有します。

9. 定期的なレビュー:

  • Eメールの環境やセキュリティの要件は時間とともに変わる可能性があります。定期的にARCの設定や運用をレビューし、必要に応じて更新または調整を行います。

ARCの実装は、Eメールの信頼性とセキュリティを向上させるための重要なステップとなり得ますが、上記のステップや考慮点を参照して、計画的かつ慎重に進めることが重要です。

タイトルとURLをコピーしました