生成されたレコードは決定アーティファクトです
A DMARCレコード ジェネレーターは、提案されたポリシーをフォーマットすることはできますが、組織がどの正当な送信者を抱えているか、組織がどのようなビジネス リスクを受け入れるか、レポートの宛先が承認されているかどうかを決定することはできません。出力では、各ポリシーの選択とその背後にある前提を説明する必要があります。これらの決定が行われていないコピー可能な文字列は、組織の実際のメール フローに適合しない、構文的に妥当なポリシーの公開を促進する可能性があります。
RFC 9989 現在のポリシーの形式とメカニズムを定義します。この記事では、ジェネレーターと注釈付き出力レビューの要件を提案します。 EmailAuthジェネレーターを実装したり、運用可能なレコードを生成したり、 DNSを変更したりすることは主張しません。必要な元のテスト ケースと運用上の証拠は、説明の枠組みから切り離されたままになります。
ポリシーのドメインと所有権を確立する
ポリシーが準備されているドメイン、ビジネス所有者、 DNSパブリケーション所有者、および範囲内の正当な送信ワークフローを記録します。送信者が使用するドメイン ID からポリシーが公開される正確な所有者名を区別します。ジェネレーターは、表示ラベルまたは想定される組織境界に基づいて親ドメインまたは子ドメインを暗黙的に選択すべきではありません。
現在のポリシーの検出には、以下が含まれます。 DNSツリーウォーク によって説明されました RFC 9989。ジェネレーターのアノテーションは、次のことを約束するのではなく、意図した範囲と、見直しが必要な継承関連の前提を説明する必要があります。 記録 ユーザーが入力したアドレスにのみ影響します。実際に適用可能な動作は、標準および受信機の実装によって異なります。この作業中に、ドメイン階層や既存のポリシーは照会されませんでした。
要求されたポリシーと準備状況を説明する
要求されたポリシーは、プロトコルに基づくドメイン所有者の評価設定を表します。これは、受信者の最終的な処分を保証するものではなく、すべての正当な送信者が準備ができているという声明でもありません。施行を推奨する前に、送信者ごとの準備状況のレビューと、残りの障害に関する承認された決定を要求します。ジェネレーターは選択肢と結果を提示できますが、その背後にビジネス上の承認をでっち上げるべきではありません。
説明する アライメント ポリシーの重大度とは別に選択できます。表示されている From ドメイン、認証済み SPF アイデンティティと DKIM 署名ドメインには関係が定義されています DMARC。厳格な調整と緩和な調整は、単に全体的なセキュリティの強化と弱さを示すラベルではありません。その運用上の影響は、組織のドメイン構造と送信サービスによって異なります。選択した根拠と未解決の依存関係を注釈付き出力に保持します。
現在のバージョンとタグのセマンティクスを保持する
RFC 9989では、依然として大文字と小文字を区別するバージョン値DMARC1を指定しています。ジェネレーターは、新しい標準文書を DMARC2 への切り替えとしてアドバタイズしてはなりません。バージョン タグの必要な位置と値は、現在の形式に従って検証される必要があります。正式な定義に基づくプロトコル処理では、未知のタグは無視される必要があるため、ツールは、サポートされていないタグの警告と、未知のタグがすべてポリシー全体を無効にするという作成されたルールとを区別する必要があります。
付録 A.6 では、pct の削除と、y および n の値を使用した t の導入について説明します。現在のジェネレーターは、あたかも現在の標準的なコントロールであるかのように、廃止されたパーセンテージ スライダーを引き継いではなりません。また、過去のすべてのパーセンテージを t に置き換えることが安全な普遍的な移行であると想定すべきではありません。対象となる標準、正確なテストのセマンティクス、および対象の環境に残る互換性に関する質問を文書化する必要があります。
報告先を承認済み受信者として扱う
RFC 9990 外部宛先の集計レポートと検証を定義します。ジェネレーターは、レポート要求の発行とレポートの受信が異なるステップであることを説明する必要があります。提案された受信者、データの目的、および該当する外部宛先の承認が行われているかどうかを特定する必要があります。ユーザーがアドレスをフォームに貼り付けたからといって、承認を推測しないでください。
この記事は、報告先アドレスを提供したり、承認記録を公開したり、第三者にデータを送信したりするものではありません。提案された出力では、宛先が承認されるまで、明らかに動作しないプレースホルダーを使用する必要があります。注釈には、レポートの可用性が受信者と配信に依存するため、URI を含めることは完全な観察を保証するものではないことも明記する必要があります。障害レポートの選択肢が提供される場合、集計レポート設定に無造作にバンドルされるのではなく、独自のサポートされる仕様とプライバシーのレビューが必要になります。
既存レコードと重複の処理について説明する
生成者は、提案されたポリシーが既存の公開された状態にどのように関連しているかを尋ねる必要があります。同じ所有者で 2 番目のポリシー候補を作成すると、承認された既存のレコードを置き換える場合とは異なる結果が生じる可能性があります。したがって、出力には、単にこれを追加するというものではなく、意図した正確な差分を記述し、復元マテリアルを保存する必要があります。 TXTレコード。既存の無関係なTXTデータは、ポリシー生成の副作用として削除されるべきではありません。
RFC 1035 TXTレコード構造を定義します。 1 つのTXTレコード内の複数の文字列は、複数のポリシー レコードと同じではありません。注釈とテストでは、エディターの表示がオペレーターを誤解させないように、その区別を保持する必要があります。ここでは既存のDNS状態は検査されませんでした。重複の処理は、検証された結果ではなく、提案されたテスト要件のままです。
注釈付き出力ワークシート
ポリシードメイン、パブリケーション所有者、提案されたレコード、各タグの意味、選択した根拠、前提条件となる証拠、承認所有者を含むワークシートを作成します。既存の状態の参照、正確な意図した差分、レポート受信者の承認、互換性の制限、検証計画、ロールバック基準を追加します。生成された構文は、承認および公開ステータスとは別に保管してください。完了したフォームは、ライブ変更を行う許可を自動的に暗示するものであってはなりません。
必須のフィクスチャ セットには、正の有効なケース、無効なバージョンまたは必須形式のケース、重複したポリシー候補、およびサポートされていないタグの動作が含まれている必要があります。現在の標準と製品のプレゼンテーション ルールから期待される結果を個別に述べます。後で承認されたテストを実行するときに、ジェネレーターのバージョン、テスト入力、および観察された出力を保持します。このドラフトはこれらのフィクスチャを生成または評価しておらず、実装への準拠については主張していません。
架空の診断: パーセンテージ スライダーが決定を隠します
架空のチームは、パーセンテージ スライダーを備えた古いポリシー フォームを使用し、より小さい数値を選択すると施行の変更が安全になると想定しています。レビュー担当者は、フォームがどの標準を実装しているか、組織の正当な送信者の準備状況、および提案された出力が関連する受信者でどのように動作するかを尋ねます。コントロールの外観では、これらの質問には答えられません。
提案された対応策は、スライダーを別のタグに機械的に変換するのではなく、現在の標準にリンクされた動作を取得し、ポリシー決定を文書化し、正確な変更計画を検証することです。実際のジェネレーターやプロバイダーはこの行為で非難されていません。この演習は架空のものであり、レコードは生成されず、 DNS変更や受信機テストは実行されません。これは、ポリシーの理論的根拠が構文とともに表示されたままでなければならない理由を示しています。
出力準備完了と呼ぶ前に証拠を要求する
有用なジェネレーターの結果には、どの入力が提供されたか、どの前提が残っているか、公開前に何が起こる必要があるかが示されます。これは、資格のある所有者が、書式設定されたテキストが安全な施行を確立していると主張することなく、一貫した意思決定を行うのに役立ちます。最終的な権限は、承認されたビジネスおよび技術変更プロセスに残ります。
カタログには、注釈付きレコードと、ポジティブ、無効、重複、およびサポートされていないタグのテスト ケースが必要です。これらのオリジナルのアーティファクトはオープンなままです。人間の専門家によるレビュー、ソースの適用性、生産ルート、アクセシビリティ、所有者の公開も未解決のままです。このドラフトは、提案されたワークシートと架空の診断を提供するものであり、すぐに公開できるポリシー、完了したテスト、または検証済みのEmailAuthツール機能ではありません。