集約された障害ごとにページングするのではなく、明確な分母、カバレッジ信号、所有者、および調査パスを使用してトランスポート セキュリティ アラートを作成します。
しきい値の前に決定を定義する
参考文献: RFC 8460 §4.1.
有用なアラートは、観察可能な状態とそれを調査できる人を識別します。状態が新しい障害カテゴリであるか、持続的な障害シェアであるか、予期されるレポーターの欠落であるか、または直接的なエンドポイント障害であるかを決定します。 TLS-RPT は集約されて遅延するため、リアルタイムの可用性監視の代替にはなりません。アラートの緊急性をその証拠と照合します。サービスが現在障害を起こしていることを証明しなくても、日次レポートが遅れても重要な場合があります。
互換性のあるスコープと分母を使用する
参考文献: RFC 8460 §4, RFC 8460 §4.2.
定義されたレポーター、ポリシー、および期間の成功セッションと失敗セッションで失敗を割ったものとして、要約失敗シェアを計算します。分母がゼロの場合を守ります。絶対的な失敗数を比率の横に置いてください。1 つのセッションのうち 1 つの失敗したセッションは 100% ですが、数千の失敗とは証拠の重みが異なります。重複する障害詳細カテゴリを合計して分母を作成しないでください。詳細が許す限り、成功のために欠落した詳細を生み出すことなく、ポリシー ドメインおよび関連する受信エンドポイントごとにセグメント化します。
例示的なしきい値を実行する
ローカル指導ルールでは、要約不合格が少なくとも 20 件で、その割合が少なくとも 5% である場合に調査が開始されます。 980 件の成功と 20 件の失敗では、シェアは 2% となるため、比率の条件は満たされません。 380 件の成功と 20 件の失敗により、シェアは 5% となり、両方の条件が満たされます。合計セッションがゼロの場合、結果はレートがなく、健全ではありません。これらの数値はラボの任意のしきい値であり、 EmailAuthデフォルト、SLA、またはすべての組織に対する推奨事項ではありません。
カバレッジを追加してコンテキストを変更する
参考文献: RFC 8460 §4.3.1, RFC 8460 §4.3.2.
失敗数の減少は、改善ではなくレポートの喪失を反映している可能性があります。輸送結果とは別に、予想されるレポーターの存在とコレクターの摂取量を追跡します。監視ウィンドウ、到着遅延、影響を受けるポリシー、および最近の関連証明書またはルーティングの変更をアラート証拠に含めます。新しい証明書ホスト不一致カテゴリは、ID チェックとエンドポイント チェックにルーティングされる必要があります。 sts-policy-fetch-error はポリシーの取得にルーティングする必要があります。直接の可用性プローブを別個の証拠ストリームとして保持し、タイムスタンプとネットワーク上の有利なポイントにラベルを付けます。
アラートを実行可能かつ元に戻せるようにする
参考文献: RFC 8460 §4.1, RFC 8460 §7.
サービス所有者、最初の診断ステップ、および終了条件を割り当てます。添付ファイルごとに 1 ページを作成するのではなく、同じインシデントから繰り返された観察をグループ化し、範囲の変更を保持します。強制を自動的に弱めたり、従来のプロトコルを有効にしたり、証明書を置き換えたりしないでください。 集計レポート コンテンツ。修復後、エンドポイントを直接検証し、遅れたレポートを確認しながら、その後の観察期間を評価します。測定されたトラフィックとビジネスへの影響からしきい値を調整し、推論を記録します。新しく再実行されたオフライン フィクスチャは、指定された算術および決定の境界のみを証明します。ライブ アラート、モニタリング サブスクリプション、または本番環境の修復は作成されませんでした。
保持されている歴史的証拠と現在のチェック
以下のトランスポート観察は、このレビューのためにネットワーク テストとして再実行されたものではなく、2026 年 11 月 7 日にキャプチャされ検査されたものです。新しいオフライン モデル チェックは個別に記録されます。
保持されている注釈付きの履歴レポートには、実際の肯定的なループバック テストとホスト名不一致のループバック テストに対応する、成功したセッションと失敗したセッションが 1 つずつ含まれています。その小さなサンプルは、意図的に例示的な 20 個の失敗しきい値を満たしていません。レポートは手動で作成されており、レポートによって発行されたものではありません MTA、通知サービスは有効になっていませんでした。運用しきい値の調整、カバレッジの監視、およびルーティングされたアラートの受け入れは、関連する運用上の証拠が保留されるまで保留されたままになります。履歴トランスポート ランナーには、暗号化とループバック ソケットを備えた Python が必要です。その結果は、限定されたラボの証拠であり、現在のサービスの健全性や運用の相互運用性ではありません。
一次情報源ベース
フィールド定義とレポート制限は次のとおりです。 RFC 8460 、 SMTP TLSレポート、セクション 3 および 4。運用上の推奨事項はプロトコル要件とは区別されます。