推測されたSPFインクルードではなく、レガシー ID から開始します
「Roaring Penguins」という名前のインベントリ エントリだけでは、送信者を構成するのに十分ではありません。歴史的な会社名は Roaring Penguin Software で、その製品にはいくつかの CanIt 亜種が含まれていました。 DNSを編集する前に、組織が実際に使用しているもの (インストールされているアプライアンスまたはソフトウェアのバージョン、ホストされたサービス、リセラー管理のルート、移行後に残された履歴ラベルなど) を特定します。この記事では、検証された現在の展開レシピではなく、監査と証拠のワークフローを提供します。
企業が発行した 2010 年 11 月のリリースでは、CanIt-PRO、CanIt-Domain-PRO、および Hosted CanIt について説明されています。発表します DKIM メールを評価する際の署名者情報の使用を含む、フィルタリング コンテキストでのサポート。この歴史的記述は、最新の顧客ドメイン署名インターフェイスや SPF 今日公開しても安全なものが含まれます。 Roaring Penguin の CanIt 7.0.8 の発表
Marlin の 2018 年 3 月の買収発表により、Roaring Penguin は AppRiver の電子メール セキュリティ ビジネスに組み込まれました。取得履歴は古いラベルの説明には役立ちますが、特定の顧客がどの後継サービスを使用しているか、古いインストールがサポートされているかどうか、またはどのDNS指示が適用されているかを証明するものではありません。 マーリン買収の発表
この調査では、正確な従来の展開に関する現在のプロバイダー所有のセットアップ ドキュメントは確立されていませんでした。検証済みの現在のセットアップ ソースがないことは、製品の廃止の証拠にはなりません。検索スニペット、サードパーティのミラーリングされたマニュアル、または買収の発表を現在の製造指示に変換しないでください。デプロイメント所有者がサポートされている参照を提供するまで、製品とソースのホールドを表示したままにしておきます。
実際のメールパスを再構築する
まず、システム所有者、サービス契約、インストールされているバージョン、管理エンドポイント、および責任のあるサポート組織から始めます。名前が表示されるレコード: メール インベントリ、 SPFメカニズム、 MXターゲット、受信ヘッダー、または請求レコード。これらの手がかりはさまざまな質問に答えます。受信パス内のフィルタリング ホスト名は、サービスが組織の送信電子メールを発信していることを証明するものではありません。
変更チケットに簡単なルート在庫を描画します。元のアプリケーションまたはメールボックス、リレーまたはフィルター、パブリック出力サービス、およびテストに使用される宛先を特定します。各ホップを観察済み、文書化済み、またはまだ推定済みとしてマークします。リセラーがサービスを管理している場合は、顧客がベンダーのオリジナルの管理インターフェイスを持っていると想定せずに、基盤となる製品とその現在のサポートの正確な範囲を特定するよう依頼してください。
制御された送信メッセージを収集し、フィルターを理解するために必要な受信サンプルを別途収集します。無害なコンテンツと許可された受信者を使用してください。個人情報を最小限に抑えて、タイムスタンプと関連するルーティング ヘッダーを保存します。製品名を含むヘッダーが信頼できる所有権の証拠であるとは考えないでください。それを組織の設定されたルートおよび受信者自身の観測と相関させます。
管理者は、レガシー コンポーネントがメールを受信するだけで、アウトバウンド トラフィックは別のプロバイダーを経由して送信されることに気づく場合があります。その場合は、アウトバウンド認証を実際の送信サービスのガイドに移動してください。レガシーコンポーネントをインバウンドサービスインベントリに保持し、すべてのインベントリエントリが「構成済み」であるように見せるためだけに送信権限を追加しないでください。
署名の検証を署名の作成から分離する
インバウンドDKIM検証では、受信した署名が検証されるかどうかが尋ねられます。アウトバウンド署名では、承認されたドメインから送信されるメッセージの署名が作成されます。有効な署名者に低いスパム スコアを与えるフィルタリング ルールでは、組織の署名は作成されません。過去の発表では、アカウント固有の署名手順ではなく、DKIM 関連のフィルタリング機能の存在がサポートされています。 Roaring Penguin の歴史的なDKIM発表
アウトバウンド署名の主張の場合は、署名システム、ドメイン、 セレクタ、公開鍵の公開、および通過した受信署名。 DKIMの sd= および s= の値は、検索で使用される署名ドメインとセレクターを識別します。古いセレクターで見つかったDNSレコードは、現在のメッセージがまだそのセレクターで署名されていることを示しません。 DKIM RFC 6376
インストールされているバージョンと展開モデルに一致するサポートされている手順については、現在のオペレーターに問い合わせてください。鍵自体を要求せずに、誰が秘密鍵を保持するか、ローテーションとリカバリがどのように管理されるかを確立します。ダウンストリーム システムが署名後にメッセージを変更するかどうかを記録します。承認された変更の前後にテストを維持し、レビュー担当者が不足している署名と後で無効になる署名を区別できるようにします。
古いマニュアルのみに基づいて、新しいセレクターを公開したり、公開キーを置き換えたり、署名制御を切り替えたりしないでください。歴史的に信頼できる手順であっても、変更されたサービスやサポートされていないインストールでは間違っている可能性があります。安全な次のステップは、推測されたメニュー パスではなく、証拠のリクエストと範囲を絞ったテスト計画です。
観察されたアイデンティティにのみSPFとDMARCを評価する
送信メッセージのSMTPエンベロープ ドメインとパブリック出力パスを特定します。 SPF 、評価されたSMTP ID の送信システムを許可します。受信フィルタリング サービスが送信者になるわけではありません。既存の正当な承認を保持し、各所有者で適用可能なSPFポリシーを 1 つ維持し、代替を提案する前に検索制限を評価します。 SPF RFC 7208
ここにはユニバーサル Roaring Penguin は含まれていません。現在のプロバイダーの指示または管理者が検証した正確なルートの出力詳細を取得します。アーカイブされた例に含まれているという理由だけでドメインを再利用しないでください。提案された各アクセス許可をアクティブなメールに結び付ける証拠を、それを確認できるサービス所有者を含めて記録します。
次に、渡されたSPFまたはDKIMドメインと、表示されている From ドメインを比較します。 DMARC ヘッダー内のどこかに古い製品名や認証パスが存在するだけでなく、整合されたパスを渡す必要があります。適用する RFC 9989 そして、受信者の結果をそれを説明するドメインとともに保存します。 DMARC RFC 9989
ルートをサポートまたは検証できない場合は、メール所有者とともに制御された移行を計画してください。まず重要な送信者のインベントリを作成し、置換ルートを確立し、検証します。 アライメント そこに、そして文書の回復。残りのトラフィックと依存関係がチェックされるまで、古いレコードを削除しないでください。
架空の診断: 受信フィルターが送信送信者と間違われる
架空の組織は、メール文書に Roaring Penguin ラベルがあるのを見て、新しいSPFインクルードを追加する必要があると想定します。調査者は送信テストを追跡し、従来のフィルタが受信メールにのみ存在することを発見しました。メッセージは実際には、個別に管理されるリレーを通じて送信されます。この考えられたシナリオは、測定された Roaring Penguin の展開ではなく、在庫エラーを示しています。
チームはリレーのエンベロープとDKIM ID を検証し、その認証作業をリレーの所有者に割り当てます。受信フィルターのサポートに関する質問はオープンのままですが、推測的なSPF変更は行われません。 2 番目のレビューでは、何かを廃止する前に、古い署名セレクターがまだ使用されているかどうかを確認します。その結果、不必要な承認によって作成されたグリーンステータスではなく、修正されたルート在庫と正当な変更計画が得られます。
レガシールートワークシート
- ID: 過去のラベル、正確な製品、バージョン、展開モデル、オペレーター、および現在のサポート連絡先。
- 方向: 受信フィルタリング、送信リレー、署名、または未解決。各分類の証拠を含めます。
- ルート: 元のワークロード、中間システム、パブリック出力、タイムスタンプ、および承認されたテスト受信者。
- 認証: 表示される From、エンベロープ ドメイン、 DKIM d=/s=ペア、信頼できる結果、およびアライメントの検出。
- ドキュメント: 現在のプロバイダーのリファレンス、バージョンの適用性、発行された公開値、および未解決の機能。
- 移行: 必要に応じて置換、重要な送信者、ロールバック所有者、および廃止の依存関係がサポートされます。
出版境界
これは、明示的な実装保留を備えた完全な従来の監査候補です。現在のプロバイダー固有のSPF値、セレクター、またはインターフェイス プロシージャは検証されていません。ライブ デプロイメント、 DNS 、ヘッダー、ビジュアル、人間の SME、および公開ゲートは保留中のままです。出版前に、編集者は、解決された証拠がセットアップ ガイドをサポートしているかどうか、またはトピックを明確にラベル付けされた従来の評価のままにするかどうかを決定する必要があります。
歴史的証拠を、それが証明できるものによってラベル付けする
2010 年のリリースでは履歴フィルタリング機能が確立され、2018 年の発表では取得履歴が確立されています。どちらも、アクティブな顧客ルート、現在のサポート資格、または後続の署名構成を確立しません。これらを現在のオペレーターに対する別の質問として記録します。会社の歴史を実行可能なDNSレシピにしないでください。
ポリシーのロールアウトからメッセージの受け入れを分離する
整列されたSPF結果が合格すればメッセージ評価を満たすことができますが、それだけではドメイン全体を拒否するように移動することは正当化されません。 RFC 9989セクション 7.4 では、ドメイン公開に有効なDKIMが必要です p=reject そして、間接メールの相互運用性について警告します。ポリシー所有者が施行を承認する前に、すべての正当な送信者と間接ルートをインベントリします。この記事では、 DNS変更、テナントの操作、受信メッセージのテストは実行されていません。