航空会社の旅程の変更と空港サービス勧告は、乗客の受信箱では似ているように見えますが、権限、期限、システムが異なります。空港ドメインを航空会社の交換可能なエイリアスとして扱ったり、旅行通知プロバイダーが両方のエイリアスを代弁できると想定したりしないでください。最初のタスクは、それが誰のメッセージであり、誰がルートを操作しているかを確立することです。
権限と緊急性を一緒にマッピングする
架空の地図は、旅程の変更を旅客メッセージングに、空港勧告を空港運営メッセージングに、一般的な旅行通知を別のサービス所有者に割り当てます。ルートごとに、メッセージを作成したイベント、対象の受信者、作成者のドメイン、および最新の有用な受信時刻を記録します。一般的な電子メール ダッシュボードではなく、運用所有者がその期限を定義する必要があります。
考案された飛行基準と明確にマークされた試験勧告を使用してください。乗客、運航乗務員、または公共の配布リストにテスト中断メッセージを送信しないでください。エンドツーエンドのテストは、認証されたアカウントと環境でのみ実行し、合成アラートが実際の操作指示と間違われないように手順を実行します。
配達を請求せずに本人確認を行う
有効な調整された署名は、主張されたドメイン ID をサポートします。これは、メッセージがキューを抜け出したこと、出発前に乗客に届いたこと、または正しいゲートが含まれていることを示しません。この例では、旅行通知ベンダーは notification-vendor.test で署名し、From は travel.fly.test を使用します。署名が有効であると仮定しても、これらの仮想ドメインは厳密には失敗します。 DKIM アライメント。これは実行されたアイデンティティ テストではなく、完全ではありません DMARC 評決。
レコードを変更する前に、プロバイダーの文書化された ID オプションとサービスのアカウント所有権を確認してください。航空会社と空港のドメイン権限を分離してください。空港運営チームの承認は、組織が旅行で協力している場合でも、航空会社のドメインからの送信を許可するものではありません。
適時性をそれ自身の結果として測定する
SMTP 、一時的な失敗後の再試行が許可されています。 RFC 5321セクション 4.5.4 では、再試行の動作について説明しています。電子メールが航空期限に間に合うことを約束するものではありません。イベントの作成、アプリケーション キューの終了、プロバイダーの受け入れ、および制御された受信を個別に記録します。有効な受信期限が 10:10 で 10:00 に作成され、10:13 に受信が行われる架空のイベントは、認証が成功した場合でも遅れます。
計算すると、10:13 マイナス 10:00 = 13 分、10:13 マイナス 10:10 = 3 分遅れます。これらは作成されたタイムスタンプであり、実行されたクロック モデルではありません。ネットワークのキューを再現したり、航空会社のベンチマークを行ったりするものではありません。実際のテストでは、すべてのシステムが正確な時間を共有しているかのように振る舞うのではなく、クロック ソースを文書化し、タイムスタンプの不確実性を考慮します。
承認された運用チャネルを維持する
電子メールが遅延したり利用できない場合は、組織が確立した安全手順と乗客への通知手順を使用してください。このガイドは、電子メールを安全性が重要な管理として承認したり、運用上の警告システムを置き換えることを推奨したりするものではありません。導入前に回復所有者を定義し、失敗した通知ルートを分離し、必要に応じて以前の承認された構成を保持します。航空規制、アクセシビリティ、乗客の権利、保持義務については、資格のある審査が必要です。認証パスは、操作の許可でもコンプライアンスの証明でもありません。
架空の路線図
次の明示的な ID は入力例であり、実際の顧客の構成ではありません。これらのドメインと責任ある役割は仮説的なものであり、顧客の承認や提供された署名付きメッセージではありません。暗号化テストや配信は実行されませんでした。
- 旅程の変更: 乗客へのメッセージングのリード。 itinerary.fly.test より;エンベロープとDKIM署名者 itinerary.fly.test。
- 空港運営アラート: 空港運営メッセージングリード。 ops.airport.test から;エンベロープとDKIM署名者 ops.airport.test。
- 旅行通知: 旅行通知のリーダー。 travel.fly.test より;エンベロープとDKIM署名者 notification-vendor.test。
遅れた出来事と救済策を追跡可能に保つ
各タイムスタンプの実際の証拠ソースと併せて、通知の有用な期限を記録します。クロックや受信の観察が決定に影響を与えるほど不確実な場合は、正確な配信パフォーマンスを主張するのではなく、その不確実性を可視化したままにしてください。認可された操作所有者は、確立された応答を選択する必要があります。この記事は安全手順を作成したり、乗客への対応を承認したりするものではありません。
RFC 9989セクション 4.4、5.3.5、および 5.4 認証をタイミングや内容の保証に変えないでください。完全なメッセージ判定のために、関連するすべての整列されたパスを評価します。のために p=reject デプロイメントでは、セクション 7.4 および 8 では、有効な DKIM ではなく有効なDKIMが必要です。 SPF 一人で。 13 分間の例は、算術演算のみを証明するものであり、航空会社の準備状況を証明するものではありません。