ポータルは、アプリケーションの受信が失敗してもアプリケーションを受け入れることができ、ステータス更新が忘れられたリレーを使用しているときにリマインダーを正常に送信することもできます。どちらの場合でも、国民はサービスの停止を経験します。複合的な認証メトリックに依存する前に、受信、リマインダー、およびステータス通知を 3 つの独立して所有されるルートとして扱います。
各通知を状態遷移に結び付ける
受領書の場合、それを作成するアプリケーション イベントと、それを送信に結び付ける識別子を特定します。予定のリマインダーとして、スケジュール システム、タイム ゾーン、および再スケジュールの動作を記録します。ステータスの更新については、ケース管理の移行状況と、市民がそれを確認できる権威ある場所を特定します。通知時刻を基礎となるイベント時刻とは別にしてください。
各イベントを送信側アプリケーション、ベンダー テナント、From ドメイン、 封筒の差出人, DKIM ドメインと セレクタ。 Web ポータルのドメインとTLS証明書には、どのシステムが電子メールを送信するかが示されません。アプリケーション統合では、すべてのメッセージが同じビジュアル デザインを共有している場合でも、通知ファミリーごとに異なるプロバイダーを選択できます。
ハッピーパスだけでなく、変更を中心にテストを設計する
架空のアプリケーションと承認されたテスト メールボックスを使用します。可能な場合は、承認されたテスト環境で、提出、予定の変更、キャンセルされた予定、およびステータスの変更をトリガーします。最終メッセージのバイトと受信者の信頼できる認証結果を検査します。一般的なテストログに実際の市民のケースの詳細を含めることなく、リンクと表示された参照が期待される公式サービスにつながることを確認します。
再スケジュールする前にキューに入れられたリマインダーは、正しく署名されていても、古い予定について説明されている可能性があります。ドメイン認証ではアプリケーションの欠陥は解決されません。通知の元のイベントとバージョンを追跡して、操作で古いコンテンツと ID エラーを区別できるようにします。同様に、重複したレシートは、自動的に次のように分類されるのではなく、イベントまたは再試行の問題として調査される必要があります。 スプーフィング.
誰が壊れた旅を止めるかを決めてください
アプリケーション所有者は、電子メールが利用できない場合に国民が安全に続行できるかどうかを判断する必要があります。スケジュール管理者はリマインダーの不一致を処理し、ケース操作はステータス通知を処理する必要があります。ポリシーを強化する前に、承認された代替ステータスチェックパスとエスカレーション連絡先を定義します。本当にサポートされ、スタッフが配置されていない限り、代替チャネルを約束しないでください。
送信者が調整されていない場合は、サービスの実際のカスタム ドメイン機能とテナントが生成したレコードを確認します。承認された ID パスのみを変更してテストし、日付付きのロールバック計画を保持します。広範囲を避ける SPF ソース IP に見覚えがあるという理由だけで追加が行われます。プロバイダーは、確立に失敗しながらも独自のドメインを認証できる アライメント 公共サービスの From ドメインを使用します。
単なるパーセンテージではなく完全性を監視する
どの通知ファミリーが観察され、どの通知ファミリーがテストされ、どの通知ファミリーが未検証のままであるかを記録します。別のテンプレートやシステムを使用する場合は、頻度の低いライフサイクル イベントや現地言語のバリエーションを含めます。使用 集計レポート 実際のレポート対象範囲内のパターンを特定し、サービス証拠を使用して欠落ルートまたは障害のあるルートを調査します。ポータルのアップグレード、スケジューラの変更、ベンダーの交換、From ドメインへの変更後にマップを更新します。ここでは、特定の法定通知期限は主張されません。
3 つの書面によるルート記録に取り組む
これらの予約済みのサンプル ドメイン、セレクター、ロール、および受け渡すDKIM前提は架空のものです。これらの場合、署名されたメッセージ、キー、暗号検証、 DNSルックアップ、 SMTPトランザクション、またはライブ サービス テストは提供されず、実行されません。以下の推論を検証するために、テスト コードや外部サンプルは必要ありません。
- 領収書: 表示されます ドメインからのreceipts.civic.example ; DKIM d=receipts.civic.example;セレクターデモ1;この書面による場合のみDKIMパスを想定してください。 SPF MAIL FROM の身元と結果は不明。他の署名は不明。実際のポリシーの検出と配信は不明です。提案された所有者: アプリケーション サービスの所有者。次のアクション: このテナントの承認されたサンプルと信頼できる受信者の結果を取得します。
- 予定のリマインダー: ドメインappointments.civic.exampleから表示されます。 DKIM d=appointments.civic.example;セレクターデモ2;この書面による場合のみDKIMパスを想定してください。 SPF MAIL FROM の身元と結果は不明。他の署名は不明。実際のポリシーの検出と配信は不明です。提案された所有者: スケジュールの所有者。次のアクション: 最初のルートの結果を継承するのではなく、この別のルートとそのビジネス イベントを確認します。
- ステータス通知: ドメインstatus.civic.exampleから表示されます。 DKIM d=provider.example.net;セレクターデモ3;この書面による場合のみDKIMパスを想定してください。 SPF MAIL FROM の身元と結果は不明。他の署名は不明。実際のポリシーの検出と配信は不明です。提案された所有者: ケース管理の所有者。次のアクション: 検証済みのサプライヤーに、このテナントでサポートされている調整された署名パスを問い合わせます。許可をネットワーク全体に拡大しないでください。
最初の 2 つの規定された署名では、d= は From ドメインと正確に等しいため、識別子は厳格なアライメントと緩和されたアライメントを満たします。 DKIM結果が成功したと規定されている場合、それらの仮想メッセージに対して調整された認証パスが存在します。 3 番目の署名者は作成者ドメインとは意図的に無関係であるため、その調整されたパスを提供できません。 3 番目のメッセージを「a」と呼ばないでください。 DMARC 失敗: アライメントされたSPFまたは別のアライメントされたパス DKIM署名 まだメカニズムを満たす可能性がありますが、それらの入力は不明です。どの行からも実際の展開や受信トレイの配置を推測しないでください。
暗号署名は、署名ドメインの責任を認証するものであり、すべての命令の真実性や承認を認証するものではありません。対象となる正規化されたバイトを変更すると、署名が無効になる可能性があります。目に見えるすべての編集が必ずしも署名付き入力を変更するわけではありません。認証とアプリケーションレベルの受け入れは分離されたままになります。
古いリマインダーの例を解決する
架空のケース C-01 の予定のバージョン 1 が 10:00 GST であり、バージョン 2 では同日の 11:00 GST に移動すると仮定します。すでにキューに入れられているバージョン 1 リマインダーは、調整されたDKIMを渡すように規定されています。その同一性の結果は、10:00 を現在のものにはしません。スケジュール管理者は、承認されたキャンセルまたは代替ルールを適用し、公式ポータルで現在の予定を確認し、修正が実際に配信されたかどうかを確認する必要があります。メッセージにバージョン 2 が含まれているものの、信頼できる認証証拠がない場合は、メール ルートを個別に調査してください。ここでは、実際のケース、メッセージ、ジョブの再スケジュール、または修正の送信は使用されていません。
準拠を主張せずに標準を適用する
RFC 9989セクション 4.4 および 5.3.5 アライメントと機構の区別をサポートします。そのセクション 7.4 では、間接メールの相互運用性について警告しています: を使用するドメイン p=reject SPFだけではなく有効なDKIM使用する必要があり、汎用メーリング リストの使用には特に注意が必要です。ルート インベントリ自体は拒否を強制する許可ではありません。 RFC 6376セクション 3.4 ～ 3.7 および 6.1 署名された入力と検証について説明します。 RFC 9990セクション 3.1 受信者ごとの到着証明ではなく、レポートのコンテキストを提供します。 RFC 5321セクション 4.2.5 サーバーの受け入れ責任とその後の配信結果を区別します。ここでの部門ワークフローの選択は編集者の推奨事項です。法的範囲、要素の適合性、および現地の認可は、独自の責任あるレビューが必要です。