ARC は、メッセージを変更する可能性のある仲介者間で認証評価を実行するように設計されています。これにより、以前の処理に関する証拠が追加されます。仲介者が元の作成者になることも、最終受信者がメッセージを受け入れることを要求することもありません。 ARC結果を、現在の認証および不正使用の制御と並行して、受信者の決定への 1 つの入力として読み取ります。
3 つのコンポーネントを読む
参考文献: RFC 8617 §4.1.1, RFC 8617 §4.1.2, RFC 8617 §4.1.3.
ARCセットにはARC-Authentication-Results 、 ARC-Message-Signature 、および ARC-Seal。 1 つ目は仲介者の評価を含みます。 2 つ目は、 ARCフレームワークでメッセージのコンテンツに署名します。シールは、 ARC材料を規則的なチェーンに結合します。インスタンス番号は、各セットに属するコンポーネントを接続します。 RFC 8617のセクション 4 と 5 では、構造と処理を定義します。
以前に報告されたdmarc=passは中間者によるアサーションであり、最終受信者によって計算された新しい結果ではありません。有効なシールは、検証ルールに基づいて署名ドメインとの暗号化関係を確立します。それは、ドメインが信頼できる裁判官であること、そのシステムが妥協していないこと、またはそのドメインが以前に主張した評価が正しかったことを証明するものではありません。
合成パスをたどる
参考文献: RFC 8617 §5.2, RFC 8617 §7.2.1.
author.example forwarder.exampleに送信することを検討してください。これにより、フッターを適用する前に位置合わせされたパスが記録されます。最終メッセージは現在のメッセージに失敗する可能性があります DKIM 変更とフェイルアライメントのため SPF 仲介経由で届くからです。 ARC 、チェーンを検証し、その仲介者に依存する理由がある受信者の初期の評価を実行できます。
チェックポイントにはi=1,およびcv=none.署名プレースホルダーには、署名ではないことが表示されます。動作するARCセットであるかのようにメッセージに貼り付けてはなりません。コンパニオン実行可能モデルは、チェーンの有効性と信頼性の入力を提供し、信頼できない有効なチェーンも信頼できる無効なチェーンもその例示的なオーバーライドの対象にならないことを示します。
オーバーライドをパスから分離する
参考文献: RFC 8617 §7.2.1, RFC 8617 §9.3, RFC 9989 §7.4.
受信者は処分を決定する際に、信頼できる以前の証拠を使用する可能性がありますが、ローカルで観察された証拠は DMARC 結果は明確なままです。現在の認証、チェーン検証、スケーラーの信頼、および最終処理を個別に記録します。ローカル ポリシーを通じて受け入れられたメッセージには、別の認証メカニズムを通過したものとしてラベルを付け直す必要はありません。
玩具モデルには、悪意のあるコンテンツと、それ以外の場合は有利な入力も含まれています。そのフィルタリングの決定では依然としてそのケースが拒否されます。これは独自の保守的なポリシーの例であり、規範的なARCアルゴリズムやGmailや Microsoft の動作の予測ではありません。最初のおもちゃのモデルでは、署名も検証も行われません。以下の保有ラボでは、プロバイダーの配信を行わずに、制御されたキー検索を使用して実際のARC暗号化を記録します。
標準ステータスを最新の状態に保つ
2026 年 11 月 8 日のIETF Datatracker チェックではRFC 8617実験的としてリストされています。 ARCヒストリックとして再分類する提案の改訂 01 は、2026 年 10 月 21 日付けの有効なインターネット草案です。その提案は再分類が完了していません。導入を決定する前に両方の記録を再確認し、プロバイダーのサポートを個別に評価してください。 RFCステータス そして 再分類作業.
既存の依存関係については、構成を変更する前に、どの信頼できる仲介者とビジネス フローが実際にARCに依存しているかを特定します。提案された依存関係については、不確実性と代替案を文書化します。保持される証拠には、本物に署名されたローカル ヘッダー チェーンと以下のローカル信頼決定モデルが含まれます。外部受信機の展開の証拠は依然として入手できません。
保存されている検査証拠
参考文献: RFC 8617 §5.1, RFC 8617 §5.2.
2026 年 11 月 7 日に保持された研究室は、最初に原著者の実際の人物であることを確認しました。 DKIM署名 そしてSPF入力。これらの結果をlab.forwarder.exampleに記録し、フッターを追加し、 dkimpy を使用して一時的なフォワーダー RSA キーを持つ実際のワンセットARCチェーンを作成します。その後、dkimpy はシールとメッセージの署名を検証します。シール後に追加された段落により、 ARC検証エラーが発生します。受信側決定コードは、設定された信頼フラグに従って、有効なチェーンの適格性を個別に受け入れるか拒否します。完全な署名および改ざんされたメッセージと検証の詳細が保持されます。 ARC署名と改ざんは、6 つのメッセージSMTPキャプチャ後にオフラインで発生しました。信頼フラグは、プロバイダーの配信結果ではなく、別の決定機能を駆動します。
保持されていたランナーと2026年11月7日に捕獲されたランナーは検査されました。このレビューではネットワーク実験は再実行されませんでした。元の実験ではループバックのみを使用し、インターネット メールは送信しませんでした。その受信者が作成する Authentication-Results 独自の小切手から得られ、それらの分野に研究室の出自が知られています。認証の結果と処理は分離されたままです。6 つのSMTPサンプルすべては、失敗したサンプルを含め、明示的なキャプチャ ポリシーに基づいて 250 を受け取ります。信頼境界は、運用メールボックス プロバイダーではなく、この管理されたラボです。 DNSアダプターは、パブリックDNSにクエリを実行するのではなく、保持されたフィクスチャの応答を提供し、 DMARCエバリュエーターは厳密なドメインの同等性のみを使用します。完全な組織ドメインの検出、運用ポリシーの解析、およびライブ デプロイメントの結果はまだテストされていません。
現在進行中の歴史的再分類草案では、異なる送信者と受信者間でARCを導入したり、ARC に依存したりしないことを推奨しています。これは、新しい依存関係を計画するときに考慮すべき結果的な提案であり、廃止が完了していない、または現在のプロバイダーがARCを無効にしていることを証明するものではありません。標準プロセスが継続する間、日付付きのプロバイダー固有の依存関係評価を保持します。