最初に質問と受信者を定義します
ベンダーは、署名の問題を診断するための証拠を必要とする場合があります。 アライメント 不一致またはレポートの不一致。組織内のすべてのドメインのすべてのレポートが必要になることはほとんどありません。まず、正確な質問、関連する製品とアカウント、対象となる受信者、および証拠によってどのような決定が可能になるかを述べることから始めます。これにより、「 DMARC データ」が不必要に広範囲に開示されることを防ぎます。
受信者が、関連するサービスの認定されたサポートまたはエンジニアリング担当者であることを確認します。見慣れた表示名や転送されたリクエストだけでは、すべての添付ファイルをそこに送信する必要があることを確立するのに十分ではありません。パッケージのドラフトは、それを送信する許可とは別のものです。この記事では準備のみについて説明しており、電子メール、アップロード、または外部共有を承認するものではありません。
影響を受けるルートと間隔にスコープを関連付けたままにします。独自の受信ワークフローを調査しているサプライヤーは、単にそれらの観察結果が同じ集合ファイルを占有しているという理由だけで、無関係な従業員メール、マーケティング、またはその他のサプライヤーのトラフィックを受信すべきではありません。
レポートで何が明らかになるかを理解する
集計レポート 送信者のインフラストラクチャとトラフィックの側面を明らかにする可能性のある技術的な観察とポリシー情報が含まれています。 RFC 9990 受信者とレポート データのプライバシーに関する考慮事項について説明します。フィールドがメッセージ本文ではない場合でも、ベンダーのタスクには不要な場合があります。最小化は、すべての集計情報が無害であると仮定するのではなく、フィールドごとの決定として扱います。
障害レポート 下に別の、潜在的により詳細な露出面がある RFC 9991。 「レポート」の一般的な承認に基づく集計概要とそれらをバンドルしないでください。レポートの種類、内容、受信者の目的を明確に特定します。診断上の質問に、より短い要約や編集された抜粋で回答できる場合は、完全な生の成果物よりも、それを優先します。 RFC 9990 、セクション 7.1 および 7.2; RFC 9991 、セクション 7.1 および 7.2
編集前にデータフィールドマップを作成する
フィールド マップには、各候補項目、それが必要な理由、正確な値が必要かどうか、提案された処理方法、およびそれを削除した場合の結果をリストする必要があります。潜在的な項目には、関連する From ドメイン、署名ドメイン、 セレクタ、エンベロープドメイン、送信元アドレス、レポート間隔、カウントおよび評価結果。それらの必要性は質問によって異なります。常に送信する必要があるユニバーサル バンドルはありません。
調整を診断したり、アカウント固有の構成を特定したりするには、正確な技術的アイデンティティが必要になる場合があります。これらの値を承認された範囲内で共有できない場合は、誤解を招く値に置き換えるのではなく、診断上の制限について説明してください。他の識別子は、関係を維持したまま削除するか、一貫して仮名化することができます。プライベート マッピングは必要かつ承認された場合にのみ保持し、デフォルトではベンダー パッケージに含めないでください。
無関係な行とドメイン、不要な受信者アドレス、メッセージの内容、内部メモと秘密を削除します。サポート アーティファクトには、パスワード、API キー、セッション トークン、または認証情報を決して含めないでください。ファイル名、メタデータ、スクリーンショット、非表示のスプレッドシートのコンテンツ、および表示されているテキストを確認します。編集された段落は、添付ファイルが最小化されることを保証するものではありません。
診断関係を維持する
有用な証拠サンプルでは、生の認証結果と整合性の区別が保持されている必要があります。質問がDMARC失敗した理由に関するものである場合、すべてのドメインを同じプレースホルダーに置き換えると、ベンダーが理解する必要のある関係が消去される可能性があります。 ID が等しいか、関連しているか、または異なるかを保持し、クエリ対象の実際のDNS名と間違われないように、合成置換に明確にラベルを付けます。
レポート間隔、関連する結果フィールド、範囲メモをまとめて保管します。選択された行のみが共有される場合は、サンプルがフィルタリングされていることを示し、選択ルールを特定します。例を単純に見せるために結果を変更しないでください。また、フィルター処理された数が組織の合計トラフィックを表すことを示唆しないでください。必要に応じて、保持されたフィールドの横にアナリストによる簡潔な説明を提供します。 RFC 9989 、セクション 4.4; RFC 9990 、セクション 3.1
承認と保持のワークシート
受信者、組織、製品、目的、正確なファイルまたはフィールド、影響を受けるドメインまたはルート、時間間隔、機密性、転送方法、保持の決定を含む承認レコードを準備します。ベンダーが資料をその事件のためにのみ保持することができるか、別の目的に使用するか、または共有できるかを確認します。一般的なサポート関係によって、無関係な再利用や広範なアクセスが許可されるとは考えないでください。
保持の決定では、ベンダー コピーと組織の作業コピーの両方に対処する必要があります。意図した期間または削除のトリガー、およびそれが重要な場合に完了を確認できる人を記録します。これはガバナンス プロセスの提案であり、ベンダー契約ですでに特定の条件が規定されているという主張ではありません。利用可能な条件や受信者のアクセスが不明瞭な場合は、送信前に解決してください。
承認するには、レビュー担当者が最終パッケージを承認されたフィールド マップと比較する必要があります。単なる説明ではなく、実際の添付ファイルに、無関係な行、隠しデータ、偶発的なシークレットがないかどうかを確認する必要があります。変更された受信者、拡張されたデータセット、または新しい目的は、同じ共有の無害な継続として扱われるのではなく、新たなレビューをトリガーする必要があります。
1 つの署名ルートに対する架空のサポート パッケージ
架空の領収書サプライヤーが、調整された問題を調査していると想像してください。 DKIM 失敗。組織の生の集計レポートには、従業員のメールやキャンペーンの観察結果も含まれています。この例では、実際のレポートやベンダー要求にはアクセスしていません。提案されたパッケージには、関連する受信ルート行、制限されたレポート間隔、関連する ID 関係、および不確実性の短い説明のみが含まれています。
従業員行とキャンペーン行は、サプライヤーの質問に答えていないため除外されます。サプライヤーが正確な署名ドメインまたはセレクターを必要とする場合、組織はその受信者および目的に対してそれらの値を承認する必要があります。それらを曖昧にする編集されたサンプルは、概念的な議論には依然として役立つかもしれませんが、実際のDNS診断には十分なものとして提示することはできません。
最終承認には、ケース固有の保持決定も記録されます。ドラフトが完了しただけではパッケージは送信されません。サプライヤーが後で完全なメッセージ サンプルを要求した場合、特に受信者またはメッセージ本文が導入されている場合、それは異なるプライバシー プロファイルを持つ新しいコンテンツ要求になります。次のステップは、自動拡張ではなく、範囲を絞ったレビューです。
証拠と公開状況
カタログには、データフィールドマップと、明示的な保持決定を伴う承認済みの最小限の証拠サンプルが必要です。この記事では、準備方法と架空のパッケージデザインのみを説明します。実際のサンプルは承認されておらず、受信者も解決されておらず、送信やベンダーの削除も確認されていません。
6 つのリリース ゲートはすべて開いたままになります。資格のあるレビュー担当者は、受信者と目的の制限を尊重しながら、提案された最小化によって診断の質問が維持されることを確認する必要があります。実際に共有する前に、実際のデータと宛先に必要な承認を取得してください。安全に作成されたドラフトは貴重な進歩ですが、ベンダーが何かを受け取ったり処理したりしたという証拠にはなりません。