ソフトウェアを選択する前に質問を定義する
DKIM2ラボでは、2 つの実装が同じ変更されたメッセージを再構築するか、エンベロープの不一致を一貫して分類するかどうかなど、狭い不確実性を解決する必要があります。 「 DKIM2動作するかどうかを確認する」という表現は広範すぎて、解釈可能な結果を生成できません。フィクスチャを選択する前に、質問、バージョン範囲、合否基準を書きます。観察された結果が自動的な製品導入ではなく、さらなる実験を正当化するかどうかについては、別途決定してください。
2026 年 11 月 8 日にレビューされたとおり、 コアスペック-09 は 11 月 1 日付けの有効なインターネット ドラフトであり、DNS-03 は 11 月 2 日付け、BCP-01 は 9 月 9 日付けです。ケースが依存するすべての文書を固定します。 「 DKIM2 」というソフトウェア ラベルは、そのパーサーが以前のリビジョンに従っている場合、またはカバレッジが異なる別のプロファイルに従っている場合には不十分です。
報告された実装と選択したビルドを区別する
の Milter 導入プロファイル -08 ドラフト DarkChain と DarkChains をその個別のプロファイルのベータ コードとして報告します。そのステータスセクションでは、寄稿者が提供した情報とIETF承認の検証を明示的に否認します。これは評価者にとってのヒントであり、独立してテストされた推奨事項ではありません。プロファイルの制限された機能と拡張された機能を、WG コア草案のすべての要件と黙って同一視してはなりません。
ソフトウェアを実行する前に、承認された計画では、リポジトリの来歴、不変のコミットまたはリリース、ビルド構成、暗号化ライブラリ、および要求されたプロトコル/プロファイルの適用範囲を特定する必要があります。サポートされていない機能は、別の実装約束の失敗したテストとしてではなく、サポートされていないものとして記録します。インストールと実行は別個の操作アクションです。このパッケージに対してソースのチェックアウト、ビルド、インストール、またはメール トランザクションは実行されませんでした。
意味のあるコントラストを備えた小さなケース セットを構築する
既存のクラシック DKIM ベースラインから開始して、テスト ハーネスが通常のメール処理と実験的な動作を混同しないようにします。次に、架空の変更されていないDKIM2パス、宣言されたフッターの変更、および宣言されていない変更を指定します。元のメッセージ バイトと変更されたメッセージ バイトを、最終的に制御されるフィクスチャに保持します。ケースによって複数の変数が一度に変更される場合、失敗によって調査対象のメカニズムがほとんど明らかにならない可能性があります。
エンベロープの不一致、ヌル本文レシピ、および一時的なDNS障害を追加します。下 コア -09 セクション 13 ～ 14、これらは交換可能な「悪質なメール」ケースではありません。 null ボディ レシピでは、以前のボディ状態をチェックできなくなります。一時的なキー検索の問題は、失敗した完了した検証とは異なる結果カテゴリになります。正確な診断と欠落している入力を保存します。
タイムスタンプの場合は、元のSMTP受け入れ時刻を保持する必要があります。リプレイ関連のケースでは、意図された配布、予期しない後続の配信、および元のインスタンスの繰り返しの観察を区別する必要があります。ソフトウェアが実際に観察結果を生成するまで、予想されるすべての結果を仮説としてマークします。このパッケージは、実行されたサンプル メッセージや作成されたパスを含む結果テーブルではなく、オリジナルのケース設計を提供します。
再生に必要な入力を保存する
承認された実行ごとに、不透明なケース識別子、メッセージバイト ハッシュ、 封筒の差出人 受信者、受理時刻、署名者と検証者のバージョン、主要なスナップショット、および関連するポリシー記録。元のメッセージと個人データは、承認されたアクセスおよび保持プランに基づいてのみ保存してください。ハッシュはアーティファクトを識別します。欠落したバイトを再構築したり、診断が主張されたプログラムからのものであることを証明したりするものではありません。
期待される結果、観察された結果、およびレビュー担当者の解釈を分離します。レシピの再構築、署名検証、チェーン チェック、ドメイン マッチングなど、失敗候補の中間出力を保持します。最初に解析が失敗したためにハーネスが意図したチェックに到達しなかった場合は、その事実を記録します。実行全体でエラーが返されたという理由だけで、ダウンストリーム機能をテスト済みとして報告しないでください。
2 番目の実装は、同じ固定された動作をターゲットにしていることを確認した後でのみ使用してください。 2 つのプログラム間の一致は役に立ちますが、正確さの絶対的な証拠ではありません。彼らはコードを共有したり、同じ間違った仮定を共有したりする可能性があります。同様に、古いドラフトを実装した場合でも、意見の不一致が自動的に欠陥になるわけではありません。バージョンの比較は脚注に隠れるのではなく、結果の横に表示されます。
実行前に安全性とプライバシーを確認する
レシピでは、表示されるメッセージから削除された内容を保存できます。したがって、最初のラボでは合成コンテンツが望ましいです。可逆的編集テストでは、証拠アーカイブに本当の秘密が再導入されるべきではありません。制御された受信者、分離された署名キー、および所有者が実験を承認した名前空間を使用します。意図しない配信、転送ループ、または一方的なリプレイ トラフィックを防ぐ制限を設定します。
説明のない送信メール、予期しない受信者の拡大、運用環境のDNSへの影響、またはログに表示される機密コンテンツに対する停止条件を指定します。実験を正常に成功させるためだけに、確立された認証やフィルタリングを無効にしないでください。クリーンアップでは、テスト署名、記録、アーティファクト、資格情報をカバーし、保持の必要性については別途文書化する必要があります。最後のメッセージが配信されただけでは実験は完了しません。
報告と展開の結論は控えめに保つ
の BCP-01 ドラフト DKIM1 / DKIM2混合動作について説明し、 DMARC 統合がオープンしました。発行済み RFC 9989 は依然として独自の認証メカニズムを定義しています。実験結果によってその仕様を修正したり、すべての外部受信者が実験メッセージを同じ方法で解釈することを確立したりすることはできません。
同様に、 RFC 9990 集計レポートと RFC 9991 障害レポートは、開発者が収集したいあらゆる実験フィールドの汎用トランスポートではありません。ローカルのラボ診断を、サポートされているレポート形式とは区別してください。外部レポートが欠落していても拒否の証拠にはならず、受信したレポートによって完全なDKIM2検証パスが自動的に公開されるわけではありません。
未完成の証拠を明確に述べる
正確な手数料は次のとおりです: ラボの範囲、バージョン、ケース、結果、実験と本番の境界を記録します。範囲、現在の文書バージョン、および提案されたケースがここに保持されます。ソフトウェアピン、実際の実行、観察された結果、再現性チェック、検証されたクリーンアップは含まれていません。したがって、原本証拠のゲートは開いたままになります。ラボの成功、セキュリティ保証、またはEmailAuth機能は主張されていません。
技術所有者はプロトコルの解釈を承認する必要があり、セキュリティ所有者は実際の実験を承認する必要があり、独立したレビュー担当者は次の段階の決定の前に結果として得られた証拠を評価する必要があります。制作への適用性、サイトと視覚的な受け入れ、および出版許可は依然として別個のゲートとなります。優れたラボは、未完成の標準から推測される新しい生産要件ではなく、他のエンジニアが挑戦できる限定された答えを生成します。