全か無かのレビューを避ける
プロバイダーのヘルプ ページでは依然として引用されている場合があります。 RFC 7489 現在のアカウント画面またはサポートされている送信ルートを正確に説明しながら。逆に、新しい日付のページでは、過去のプロトコルのアドバイスを繰り返すことができます。有用な検討単位は、引用の古さだけではなく、個々の指示または主張です。監査人は、何が有効であり、何が現在の標準に変更され、何がプロバイダーの実際の実装に依存するかを特定する必要があります。
RFC 9989 現在のコアを提供します DMARC 仕様を説明し、 RFC 7489からの変更点について説明します。集計レポートと失敗レポートは、以下で個別に指定されるようになりました。 RFC 9990 そして RFC 9991。これらのソースを使用してプロトコル ステートメントを評価しますが、プロバイダーがすべての UI フィールドを変更したり、エバリュエーターをデプロイしたりした証拠としてそれらを扱わないでください。 RFC 9989 、付録 C; RFC 9990 、セクション 1; RFC 9991 、セクション 1
正確な製品コンテキストを保持する
ガイドに注釈を付ける前に、その URL、保持日、製品、プランまたはアカウントの範囲（記載されている場合）、地域、ルート、および関連する前提条件を記録します。ベンダー ブランドには、異なる構成パスを持つ複数のメール製品を含めることができます。カスタムSMTPルートのガイドは、デフォルトの API ルートには適用されない場合があります。また、あるホスト型メール製品の手順は、同じ会社の別の製品には適用されない場合があります。
アカウントによって生成された値を説明的な例とは区別してください。ガイドのサンプル セレクタ または、 DNSターゲットをユニバーサル実稼働値としてコピーしないでください。同様に、UI 命令は、周囲の標準の説明を更新する必要がある場合でも、引き続き有用です。歴史的な RFC が序文に登場するという理由だけで読者が有効なオンボーディング前提条件を破棄しないように、その区別を維持してください。
この原稿は、指定されたプロバイダーの現在のアカウントを監査したり、特定のサービスがコンプライアンス違反であると主張したりするものではありません。これは、将来の情報源に基づいたレビューのための方法を提供します。実際の製品説明書は、該当するものとして提示される前に、可読な主要ガイドおよび承認されたアカウントのコンテキストと照合して確認する必要があります。
各指示を権限ごとに分類する
製品ワークフロー、プロトコル要件、プロバイダー固有の資格またはポリシー、および説明的な推奨事項の少なくとも 4 つの注釈カテゴリを使用します。製品ワークフローには、現在のプロバイダーの証拠が必要です。プロトコル要件には、適切な仕様セクションが必要です。プロバイダーの適格性は、プロトコルの最小値よりも厳密であるか、範囲が異なる場合があり、すべての受信者に一般化してはなりません。推奨事項は、その根拠と限界を明らかにする必要があります。
各行にアクターと条件を記述します。受信者のポリシー検出動作は、ドメイン所有者のDNS公開タスクとは異なります。そのサービスでは、標準のレコード構文を変更せずに、特定のアカウント フィールドを構成するという要件が必要になる場合があります。レポート宛先の受信許可は、そこにレポートを送信するという送信者の要求とは異なります。
文にカテゴリが結合されている場合は、分割します。たとえば、レポート アドレスを入力する指示は有効な UI ステップである可能性がありますが、外部アドレスがレポートを自動的に受信するという主張は不完全です。レビューでは、ガイド全体を一般的なアドバイスに置き換えるのではなく、有用なステップを保存し、不足している承認条件を追加する必要があります。
変更された特定の概念を比較する
現在のコアDMARCバージョン値はDMARC1ままです。レビューでは、DMARC2 レコードをでっち上げたり、RFC 引用の更新にDNSバージョンの切り替えが必要であると示唆したりしてはなりません。現在の仕様では pct の削除も文書化されていますが、保持されているIANAレジストリではそのタグが歴史的であることがマークされています。これらの事実は、導入されたすべてのプロバイダーがそれをどのように処理するかを証明することなく、pct が現在のコア標準サンプリング制御であるという主張の修正を裏付けるものです。
ポリシーの検出と組織ドメインの決定には、古い単純化されたアルゴリズムではなく、現在の仕様との比較も必要です。報告ステートメントは、必要に応じてRFC 9990またはRFC 9991と照合してチェックする必要があります。正確な違いとその運用上の重要性を記録します。 「」は使用しないでくださいDMARCbis すべてを変えた」をセクションレベルの評価の代わりに使用しました。 RFC 9989 、セクション 4.7、4.10 および付録 A.6; IANA DMARCタグ レジストリ
注釈ワークシートと承認基準
ガイドの抜粋、ソース スナップショット、製品範囲、指示カテゴリ、現在の権限、提案された注釈、および引き続き必要な実装証拠を含むワークシートを作成します。 4 つの結果のいずれかを割り当てます: 該当するものとして保持、スコープノートとともに保持、標準主張が変更されたため更新、または未解決の保留中のプロバイダー証拠。これらは編集上の結果であり、運用システムがテストに合格したという主張ではありません。
ワークシートでは、アカウント固有の値と、動作を確立するために必要な個別に認可されたテストを確認できる所有者も特定する必要があります。プロバイダー ガイドにアクセスできない場合は、一般的なセットアップ シーケンスを置き換えて検証済みと呼ぶのではなく、ソース ギャップにラベルを付けます。
受け入れられるには、各注釈が独自の証拠に基づいている必要があります。レビュー担当者は、プロトコルの説明が改訂されている間、画面ナビゲーションのステップが保持されている理由を理解できるはずです。変更によって新しい取り組み、サポートされていない機能、または普遍的な配信可能性の約束が誤って導入されないように、元の抜粋と提案された文言をまとめて保管してください。
レガシーに引用された設定ページの架空のレビュー
架空のプロバイダー ページに 3 つの指示が含まれていると想像してください。アカウントで生成されたアカウントを入力してください。 DKIM レコードを作成し、設定画面からレポート アドレスを追加し、現在の標準のロールアウト コントロールとして pct を使用します。このページではRFC 7489を引用しています。ここではそのような名前付きページは監査されませんでした。これらの発明された命令は、分類方法を示しています。
現在の製品ドキュメントとアカウント値がそれをサポートしている場合、 DKIMステップは有効なままになる可能性があります。レポート アドレス ステップは、追加の外部承認の説明を必要としながらも、UI アクションとして有効なままである可能性があります。 pct ステートメントには現在の標準のアノテーションが必要ですが、プロバイダーによるそのフィールドの実際の処理は実装の問題として残ります。したがって、1 つの引用が 3 つの異なるレビュー結果につながります。
提案されている次のアクションは、サポートされている製品の説明書を保持し、標準言語を修正し、未解決の動作に関するプロバイダー固有の証拠を入手することです。既存のレコードをすべて削除したり、セットアップ要件を回避したり、プロバイダーが安全ではないと宣言したりすることはありません。この架空の例は、アクセスやテスト結果を過剰に主張することなく、慎重なレビューがどのように役立つかを示しています。
運用リリースと編集リリースを分離する
制限が明らかであれば、実稼働検証が完了する前に編集上の更新を行うことでガイドを改善できます。注釈付きドキュメントを、ライブアカウントが正しく構成されていることを証明するものとして記述しないでください。逆に、アカウント テストの成功は、すべての顧客のプラン、地域、または受信者の実装に一般化されるべきではありません。
カタログには、どのステップが有効のままで、どのステップが変更され、どのステップがプロバイダーの実装に依存するかを識別する注釈が必要です。実際のソース固有の注釈付きガイドは、このドラフトに対してオープンのままです。現在の指定プロバイダーのロールアウト、アカウント ナビゲーション、 DNS編集、またはメッセージ テストは要求されていません。原本証拠ゲートと他の 5 つの証拠開示ゲートは開いたままです。
公開を運用する前に、実際に読み取り可能なプロバイダーのソースを入手し、正確な抜粋、ソースの日付、および現在の標準参照を保存してください。資格のあるレビュー担当者は、保持されているすべての命令が製品の範囲と一致していること、および未解決の実装動作が未解決のままであることを確認する必要があります。このアプローチは、古い引用だけが正しいか失敗かを証明するかのように装うことなく、有用なガイドを作成します。