患者には、3 つの異なるアプリケーションが送信した場合でも、予約リマインダー、登録メッセージ、ポータル アクセス電子メールで同じロゴが表示されることがあります。各メッセージの背後にあるサービスを特定します。次に、その電子メール ID と、通知を便利かつ安全にするアプリケーションの動作の両方をテストします。
トリガーと宛先を特定する
予定の場合は、どのスケジュール イベントがメッセージをトリガーしたか、およびスケジュール変更またはキャンセルがキューに入れられたリマインダーにどのような影響を与えるかを記録します。登録の際は、メッセージと対象者を照合する責任を負うアプリケーションを記録します。ポータルにアクセスするには、アカウント サービスと承認されたリンクまたはコードのライフサイクルを特定します。ポータルの Web サイト アドレスだけでなく、実際の電子メール プロバイダーとテナントを各アプリケーションと一緒に保持してください。
From ドメイン、エンベロープ ID、 DKIM ドメインと セレクタ あらゆるルートに。返信先と承認されたポータル ホストを別のフィールドとして検査します。サービス ドメインでの有効な署名は、リンクが安全であるか、最新のものであるか、受信者を対象としたものであるかを証明するものではありません。逆に、よく知られたポータル URL は、電子メールが承認されたことを証明するものではありません。
架空のレコードによるテストのライフサイクルの変更
承認された代理予約および登録ケースを作成します。テスト環境が許可する場合は、新しい予定、スケジュール変更、キャンセル、重複登録試行、およびポータル アクセス要求を実行します。どのメッセージが実際に表示されるか、古いリマインダーがアプリケーションによって抑制されているかどうか、リンクが予期されたテスト ポータルにつながっているかどうかを確認します。
アカウント アクセス メッセージの場合は、機能しないデモンストレーション値または分離された承認済みのテスト アカウントを使用します。一般的な認証証拠には、使用可能な患者アクセス リンクやコードを保持しないでください。遅延アクセス電子メールは、トークンの有効期限が切れている間にDKIMを通過する可能性があります。これはアプリケーションのライフサイクルの結果であり、認証の欠陥の証拠ではありません。
3 種類の失敗を分離する
DKIM失敗するか、調整されたパスが存在しない場合、メール チームとサービス チームは署名、ID、およびメッセージの変更を調査する必要があります。リマインダーの時間が間違っている場合、スケジュール管理者はイベントのバージョンとタイムゾーンの処理を調査する必要があります。メッセージが古いアドレスに届いた場合、登録および ID チームは承認された受信者修正プロセスに従う必要があります。最後の 2 つの問題をリラックスすることで解決しないでください。 DMARC ポリシー。
合成ケース ID、イベント時間、送信者 ID、観察された認証、アプリケーションの結果、所有者を含む短いテスト記録を保持します。最小限の編集された証拠を使用します。 電子メールのヘッダー 個人アドレスやルーティング情報が含まれている可能性があるため、ヘッダーが公開されていると想定するのではなく、組織のアクセスおよび保持ルールに従ってそれらを扱ってください。
受け入れ決定を定義する
正しい送信 ID に加えて、メッセージ ファミリごとに予想されるアプリケーション動作が必要です。署名パスだけではポータル ジャーニーを承認できません。リマインダーやアクセス通知が失敗した場合に、未承認の代替通信チャネルを作成せずに、承認された回復パスをサービス所有者に確認します。
以下の架空のマップでは、ポータル アクセスのサンプルに、正確に一致していないプロバイダー ドメインの署名を意図的に残しています。暗号化の有効性が規定されていることから、 DKIM =pass だけを探すだけでは不十分であることが分かります。本番環境の準備には、実際のサービスの証拠と該当するものが必要です SPF またはDKIM アライメント、書かれた前提ではありません。
スケジューラの置換、登録の変更、アイデンティティ プロバイダの移行、新しいポータル ホストおよび送信者ドメインの変更後に再確認してください。キャンセルされた予定や回復されたアカウントなど、少量の例外を含めます。これは動作検証方法であり、ヘルスケア プラットフォームやEmailAuth製品がすでにこれらの制御を実装していると主張するものではありません。
書かれたルート台帳を検査する
すべての行は、予約された架空のドメイン、提案された所有者、および規定されたDKIM結果を使用します。セレクターデモ 1 は、インストールされたキーではなく、例示的なラベルです。 SPF結果、その他の署名、 DNSポリシーの検出、実際の受信およびアプリケーションの成功は不明です。キー、署名されたメッセージ、テストの実行、または配信の証拠は提供されません。
- 予約: appointments.care.exampleから; メール送信元 未知; DKIM d=appointments.care.example,セレクターdemo1、パスを想定。提案された所有者 スケジュールの所有者。次のアクション: このテナントでサポートされている署名パスとその個別のアプリケーション受け入れ基準を確認します。
- 登録: registration.care.exampleから;未知のメールからのメール。 DKIM d=registration.care.example,セレクターdemo1、パスとみなされます。提案された所有者 登録所有者。次のアクション: このテナントでサポートされている署名パスとその個別のアプリケーション受け入れ基準を確認します。
- ポータルアクセス: access.care.exampleから;未知のメールからのメール。 DKIM d=provider.example.net,セレクターdemo1、パスとみなされます。提案された所有者 ID サービスの所有者。次のアクション: このテナントでサポートされている署名パスとその個別のアプリケーション受け入れ基準を確認します。
d= が From と正確に一致する仮定された受け渡し署名は、その仮定のメッセージに厳密に調整されたパスを提供します。無関係な d= は、その署名からの位置合わせされたパスを提供しません。不明なSPFまたはその他の署名により、後者の場合の全体的な失敗の判定が妨げられます。これらの書面による前提では、ライブ構成や受信ボックスの配置は確立されません。
ライフサイクルに関する 3 つの決定を比較する
提案されたテスト テナントで架空のポータル ケース P-02 を使用します。 09:00 GST の予約バージョン 1 は、キューに入れられたリマインダーが発行される前にキャンセルされます。規定されたDKIMパスであっても、スケジュール上の欠陥が残ります。間違った合成アカウントにアドレス指定された登録メッセージは、受信者マッピングの欠陥です。 09:12 GST に観測される 09:10 GST の有効期限が想定されているアクセス リンクは、アプリケーションの有効期限ルールに基づいて評価する必要があります。認証によって有効期限は延長されません。スケジューリング、登録、およびアイデンティティの所有者はそれぞれ、期待される結果と個別の観察を記録します。ここではそれらの観測値が提供されていないため、テストに合格したものはありません。ライブトークン、患者リンク、または使用可能なコードを証拠パケットにコピーしないでください。
証拠の境界を明確に保つ
RFC 9989 セクション 4.4 と 5.3.5 では、認証と調整を区別します。セクション 5.4 では、メッセージの処理を受信側のポリシーに任せています。セクション 7.4 では、ドメイン公開にはSPF単独ではなく有効なDKIMが必要です p=reject また、ユーザーがインターネット メーリング リストに投稿するドメインを拒否しないように警告します。対象となる正規化バイトはRFC 6376セクション 3.4 ～ 3.7 および 6.1 に基づいてDKIM整合性を決定します。どちらのメカニズムも、臨床、教育、または法的権威を検証するものではありません。実際の展開のために承認された現在の証拠を収集します。ここでの運用チェックリストは推奨事項であり、管轄区域固有のコンプライアンス評価ではありません。