指示を SpamTitan ゲートウェイ署名に限定する
TitanHQ は特定の構成を公開します DKIM SpamTitan ゲートウェイの手順で。この記事はその製品境界に従います。 SpamTitan Cloud、Skellig、受信専用展開、またはすべてのマネージド サービス エディションが同じコントロールを公開するとは想定していません。署名の変更を承認する前に、インストールされているバージョン、ライセンスされた機能、および実際の送信ルートを確認してください。メール受信用にリストされているドメインは、それ自体では、送信メッセージがゲートウェイを通過したり、顧客ドメインの署名を受信したりする証拠にはなりません。
の ゲートウェイ手順 DKIM署名手順と、別個の従来の DomainKeys ポリシー レコードの説明の両方が含まれています。この混合が実装の重要な境界となります。最新の署名キーのワークフローはソースから説明できますが、従来のポリシーの手順では現在の製品の確認が必要です。古い DomainKeys 用語を黙って新しい用語に変換しないでください。 DMARC o= ポリシーを公開することで最新のドメイン保護が確立されるという要件または主張。
ドメインリレーとキーの所有権を特定する
文書化されたナビゲーションは、「システム セットアップ」、「メール リレー」、 DKIMです。このページにはドメイン リレーがリストされます。目的のドメインを編集し、[ドメイン キー] タブを開きます。この手順で要求されるのは、 セレクタ このキーを他のドメインキーと区別する名前。組織の承認された命名プロセスを通じてラベルを選択し、公開する前に既存の使用状況を確認します。予測可能なラベルは秘密ではありませんが、占有されているセレクターを再利用すると、別の送信者がまだ必要としている依存関係が上書きされる可能性があります。
ソースでは、新しいキー ペアの生成について説明しており、既存の秘密キー フィールドも提供しています。このガイドは、秘密キーをチケットまたは共有ドキュメントにコピーすることを要求、収集、または推奨するものではありません。キーの生成またはインポートは、許可された個別の管理アクションです。ガイドには 1024 ビットと 2048ビット オプションがあり、長い方の選択をお勧めします。導入された製品でサポートされている構成と現在の暗号化要件を確認します。 DNSエディターが長いパブリック値を不便に表示するという理由だけでダウングレードしないでください。
生成された公開キーをサンプルをコピーせずに公開します。
生成後、ソースは管理者を [オプション] タブとDNS TXTマテリアルに誘導します。選択したセレクター、 _domainkey 、および署名ドメインから形成された名前で実際の公開キーを公開します。ドキュメントに印刷されている大きな公開キーは例示であり、再利用可能な記録ではありません。選択した所有者と、発行されたパブリック値への制御された参照を変更リクエストに記録します。プライベートなマテリアルはパブリックDNSに属しません。
TitanHQ では、コピーされた表示から無関係な書式設定を削除することについて説明しています。これは、キーバイトの任意の編集ではなく、エディタのプレゼンテーションを処理するものとして解釈します。 RFC 6376 、セクション3.6.2.2 キーストレージのTXTリソースレコードを指定します。 DNSツールでは、単一の文字列内に複数の引用符で囲まれた文字列が表示される場合があります。 TXTレコード;これは、複数の競合するレコードや、値に挿入されるリテラルの引用符とは異なります。 DNS管理者に、入力ボックスのスクリーンショットを最終証拠として受け入れるのではなく、実際の論理レコードと完全な所有者名を確認してもらいます。
従来のポリシーとテスト モードをDMARCから分離しておきます。
また、プロバイダー プロシージャでは、ポリシー レコードの下の_domainkeyにTXTレコードが記述され、その後にドメインがo=-またはo=~値で記述されます。この DomainKeys ポリシーを明示的に呼び出します。これはDMARCポリシーの場所ではなく、 DKIMセレクターの公開キーに代わるものでもありません。この手順ではこれらの履歴要素が組み合わされているため、ポリシー ステップを追加する前に、そのポリシー ステップが正確な現在の Gateway バージョンに適用できるかどうかを確認してください。最新の要件を作成するのではなく、未解決の質問をリリース レコードに保存します。
このガイドでは、キー レコード内のDKIMテスト フラグt=y,について個別に説明しています。これを、 DMARC展開をテスト モードにする指示や、受信者がすべてのメールを受け入れるという証明と混同しないでください。 DKIM 、 DMARC 、およびローカル受信者の処理には、異なるセマンティクスがあります。 RFC 9989 、セクション 4.4 を説明します アライメント 受け渡す認証 ID と作成者ドメインの間に必要です。メールが署名されるという従来のポリシー ステートメントでは、特定の署名が検証または整合していることは確立されていません。
有効にする前に確認し、ローテーションを慎重に計画してください
TitanHQ の OPTIONS ワークフローは、Verify を使用してDNS TXTレコードを取得し、それをゲートウェイの構成情報と比較します。検証が成功すると、有効化によってドメインのDKIM署名が有効になります。これらを別のチェックポイントとして扱います。公開されたキーは署名が有効であることを証明しませんが、選択した署名オプションでは欠落または不一致の公開レコードを検証できません。検証結果とその時刻は受信機受け入れテストとして記述せずに保存してください。
ドキュメントでは定期的なキーのローテーションを推奨しています。実際のローテーション計画には、カレンダー間隔以上のものが必要です。アクティブなセレクター、生成されたキー、キューに入れられたメッセージ、 DNSキャッシュ、承認されたオペレーター、ロールバック条件を特定します。置換キーが生成されたからといって、以前の公開レコードを削除しないでください。実際のメール パスに何が重複する必要があるかを判断し、その決定を裏付ける証拠を保持します。この原稿ではキューの有効期間を測定したり、インストールされた製品の移行動作をテストしたりしていないため、実装の詳細は未公開のままです。
フィルタリングラベルではなく、最終的な送信メッセージを確認してください
別途承認された受け入れ手順では、ゲートウェイの通過、署名、検証、調整を区別する必要があります。署名の d= フィールドと s= フィールド、表示される作成者ドメイン、および信頼できる受信者の認証結果を確認します。 RFC 6376 、セクション 3.5 署名フィールドを定義します。通常のメールボックス メール、アプリケーション通知、転送されたトラフィックなど、さまざまなパスを取る可能性のあるメッセージ クラスを確認します。受信メッセージが SpamTitan によってスキャンされたという事実は、送信アプリケーション メッセージがどのように署名されたかについて決定的なものを示しません。
SPF は別レビューです。 RFC 7208 、セクション 2.4 および 4.6.4 それを説明する メール送信元 ID と DNS に依存する評価制限。このソースは、すべての SpamTitan デプロイメントにユニバーサルなアウトバウンドSPFインクルードを提供していないため、ここでは何も作成されていません。実際に承認された送信インフラストラクチャを取得し、その ID に対する 1 つの完全なポリシーを確認します。認証の成功は、受信箱の配置、コンテンツの安全性、支払い要求の受信者の承認とは区別されます。
架空の診断と白紙の合格ワークシート
架空のエンジニアリング会社 Alder Instruments は、新しいセレクター キーを公開しましたが、メンテナンス期間を待つ間、署名を無効にしたままにしました。その内部チェックリストは、検証が成功したためDKIM完了したことをマークします。その後の調査により、チェックリストではDNS契約とアクティブな署名が混同されていたことが判明しました。提案された修正は、有効化の承認、観察された構成状態、および将来の受信者の証拠を分離することです。ドキュメントのサンプル キーを公開したり、代わりに従来のポリシー レコードを追加したりすることはありません。このシナリオの基礎となる実際のシステム、メッセージ、またはDNSルックアップはありません。
- ゲートウェイ製品、バージョン、アウトバウンドルート、ドメインリレー: ______
- セレクターの所有権と既存の依存関係: ______
- 生成された公開所有者/値参照と承認されたDNS変更: ______
- 秘密鍵の保管に関する決定、機密資料なし: ______
- 従来の DomainKeys ポリシーの適用に関する決定: ______
- 結果を確認し、その後の承認/状態を有効にする: ______
- 回転のオーバーラップ、ロールバック、および前のセレクターの保持: ______
- 信頼できる受信メッセージの署名と調整の証拠: ______
- 残りの例外、レビュー担当者およびリリース所有者: ______
元の実装証拠、現在のソースの適用性、人による対象事項のレビュー、生産ルートの受け入れ、視覚的なアクセシビリティ、および所有者の公開は未解決のままです。キーの生成、設定の変更、 DNSレコードの公開、またはメッセージの送信は行われませんでした。カタログの広範な実装要件は、この文書化されたワークフローだけでは完了したとは言えません。