不動産コミュニケーションは、取引通知、テナント サービス、不動産管理業務を組み合わせたものです。これらのストリームは、エージェント、弁護士、家主、および外部委託されたプラットフォームによって、異なる ID を使用して実行される場合があります。実際のビジネス関係に基づいて送信者マップを構築し、認証チェックを適用します。ドメイン パスが、変更された銀行口座や機密性の高い取引指示を承認するためのショートカットにならないようにしてください。
支払いと検証の境界を維持する
RFC 9989 電子メールでのドメインの使用の検証をサポートします。支払い受取人が正しいかどうか、または個人が決済指示を変更する権限を持っているかどうかは検証されません。侵害された正規アカウントは、認証されたメールを送信する可能性があります。予期せぬ財務上の変化に備えて、疑わしいメッセージにのみ提供された電話番号ではなく、以前に信頼された連絡ルートを使用して、組織が確立した独立した検証プロセスに従ってください。
このガイドは、法的な譲渡義務を指定したり、金融取引を承認したりするものではありません。制御に関する推奨事項は、ID 診断とトランザクション承認を分離して、一方が他方を黙って置き換えることができないようにすることです。
関係者間で所有権をマッピングする
トランザクション通知、テナント メッセージ、およびプロパティ管理アラート用に個別の在庫行を作成します。メッセージを担当する組織、ベンダー アカウント、From ドメイン、エンベロープ ID、 DKIM ドメインと セレクタ、返信先と回復所有者。外部エージェントが独自のドメインから送信する場合は、メッセージが不動産管理者のドメインから発信されたものであるかのように振る舞うのではなく、その関係を記録します。
正規の通信相手と、ドメインを使用して送信することが許可されているサプライヤーを区別します。前者の場合は、ビジネス上の連絡先の確認が必要になる場合があります。後者には、顧客固有の構成と所有権の証拠が必要です。馴染みのあるプラットフォーム名や共有 IP アドレスは、それ自体ではどちらの関係も確立しません。
管理アイデンティティと引継ぎ権限を分離する
トランザクション通知とテナント通知ではそれぞれの From ドメインと一致する署名ドメインが使用されますが、管理通知では From management.property.exampleとd=provider.example.net.署名が検証されたと仮定しても、厳密なDKIMに失敗します。 アライメント。これらは仮説上の身元であり、署名された標本や観察されたテストが提供されたものではありません。
ここで、送信署名がまだ渡されている間に、エージェントのハンドオーバーによって承認済みの返信先が変更されたとします。正しい署名では、テナント情報を含む応答が引き続き元のエージェントに届くかどうかを確立できません。後任者の権限を確認し、変更計画に基づいて承認されたルートを更新し、非運用の架空の記録を使用してテストします。問題を証明するために実際のテナント データやトランザクション データを公開しないでください。財産の譲渡、支払い、通知、またはアクセスの変更は実行されませんでした。
実際のコミットメントを作成せずにメッセージをテストする
承認されたテストテナントまたは架空の不動産を使用し、明らかに非稼働の通知を使用します。手動で作成した模倣を送信するのではなく、実際のアプリケーション内でワークフローをトリガーします。信頼できる受信結果、送信者の ID、アプリケーション イベント、および制御された受信時間をキャプチャします。返信とリンクを個別にチェックして、テスト受信者が別のテナントの情報にアクセスできないことを確認します。
トランザクション通知の場合、テストには実行可能な支払い指示が含まれていてはなりません。代わりに、機密性の高い変更が発生したときに、ワークフローがスタッフを確立された承認プロセスに誘導することを確認してください。ビジネス所有者の承認とメール管理者の認証結果を区別してください。サービスは、そのコンテンツまたはアクセス許可が受け入れられないままであっても、正しく認証できます。
引き継ぎ時に変更を確認する
不動産の売却、管理エージェントの変更、またはプラットフォームの移行により、古い送信者とアクセスがアクティブなままになる可能性があります。承認を保持または削除する前に、各送信者と現在の所有者および目的を調整してください。承認された保存ルールに従いながら、事前通知を説明するのに十分な履歴を保存します。 1 つのベンダーの不整合による突然のドメイン全体の例外を回避します。特定の構成を修復して再テストします。新しい所有者がルートの証拠を受け入れ、失敗または不審な通知をエスカレーションする方法を知っている場合にのみ、変更を閉じます。
認証をその制限内で解釈する
RFC 9989セクション 4.4 および 5.3.5 署名の有効性、整合性、完全性を区別する DMARC 評決。単一の仮定された非整列署名は、他の整列されたDKIMの不在または整列された DKIM の通過を確立しません。 SPF パス。のために p=reject デプロイメントでは、セクション 7.4 および 8 では、 SPFのみに依存するのではなく、有効なDKIMが必要です。セクション 5.4 では、処理は受信者のポリシーに委ねられており、メッセージのビジネス内容は検証されません。これらのプロトコル境界は、承認されたワークフロー、アクセス、タイミング、または受信者のチェックに代わるものではありません。