配信通知には、複数のサーバー名、日付、アドレスが含まれることがよくあります。レポートを送信するシステムは、必ずしもメッセージを拒否したシステムであるとは限りません。レポートの件名に基づいてDNSまたはメールボックスを変更する前に、配信ステータス フィールドを解析し、元の試行を関連付けます。
レポート システムとリモート システムを特定する
RFC 3464配信ステータス本体の形式を定義しています。 Reporting-MTA は、通知を生成するシステムを識別します。リモート MTA が存在する場合、報告された配信試行に関連付けられたリモート システムを識別します。診断コードはリモート プロトコルの応答を保存できます。人間が読める説明は役に立ちますが、その散文が構造化フィールドに取って代わるべきではありません。 RFC 3464セクション 2.2 および 2.3.
システム ID と報告された時間の両方を記録します。アプリケーションからのメールを受け入れたリレーは、後で受信者サーバーから拒否を受け取り、DSN 自体を構築する可能性があります。リレーの名前を拒否宛先として扱うと、調査が間違った管理者に送信され、元のSMTP応答がわかりにくくなる可能性があります。
各受信者ブロックを個別に読み取ります
Final-Recipient は、配信ステータス ブロックが適用される受信者を識別します。 Original-Recipient が存在する場合、以前の受信者の ID を保存できます。アクションは、失敗や遅延などの配信アクションを説明します。ステータスには拡張ステータス コードが含まれます。オプションの Diagnostic-Code、Last-Attempt-Date、および Will-Retry-Until は有用な追加コンテキストを提供しますが、すべてのレポートがそれらを提供するわけではありません。
Diagnostic-Code が存在する場合、 RFC 3464セクション 2.3.6 は、提供された Remote-MTA をその発行者として解釈します。 Remote-MTA がない場合、診断は Reporting-MTA に起因すると考えられます。このフィールド ルールは、以前にリモートの試みが行われなかったことを証明するものではありません。信頼できるログで完全な履歴を裏付けます。
DSN には、さまざまなアクションとステータス値を持つ複数の受信者ブロックを含めることができます。元の To または CC ヘッダー内の全員に 1 つの失敗を適用しないでください。同様に、オプションのフィールドが欠落していても、対応するイベントが発生しなかったことを証明するものではありません。不在を不明として保存し、キューまたは追跡証拠を使用してギャップを埋めます。
仮定の有効期限通知を読む
たとえば、 relay.exampleメッセージを受け入れ、配信を試みたときにmx.exampleから 452 4.2.2 Mailbox full を受信したとします。構成された配信ライフタイムが期限切れになると、リレーは DSN を生成します。教育の抜粋では、Reporting-MTA: dns を特定できます。 relay.example 、リモート MTA: dns; mx.example 、最終受信者: rfc822; recipient@example.test 、アクション: 失敗、ステータス: 5.4.7、診断コード: smtp; 452 4.2.2 メールボックスがいっぱいです。
これは作成されたフィールドのウォークスルーであり、完全なMIMEレポートや実行されたメール交換ではありません。最終ステータスは配信時の期限切れを示し、保存された診断は最後の容量拒否を示します。フィールドはさまざまな質問に答えます。これは普遍的な優先マッピングではありません。RFC RFC 3463セクション 3.5 では、可能な場合は期限切れではなく実際の配信問題コードを返すように規定されています。サポートされている最も具体的な原因を保持します。 RFC 3464では、レポート後のアクション: 4.xx ステータスで失敗することも許可されています。 MTA 試みを放棄した。一時的な原因は、元のファイルがキューに残っていることを意味するものではありません。
独自のレポートの場合は、元の提出、試行、有効期限の決定、およびレポートの到着を個別に関連付けます。例示的な名前、タイミング、またはフィールドがプロバイダーと一致するとは想定しないでください。欠落しているオプション フィールドに推測値を入力せずに保持します。
行動する前に関連付けをする
通知を元のエンベロープ受信者、送信時刻、および使用可能なキュー ID と照合します。 Original-Envelope-Id が存在する場合、相関関係を支援することがあります。返されたメッセージ ID は、通知自体の十分な認証ではなく、もう 1 つの手掛かりとなります。レポートはなりすまし、または偽造によって引き起こされる可能性があります リターンパス したがって、予期しないバウンスによって送信者の構成変更が自動的にトリガーされることがあってはならない。
信頼された送信ログを使用して、組織が実際にメッセージを送信したことを確認します。メッセージがバウンスに似ているという理由だけで、返された添付ファイルを開いたり、認証情報のプロンプトに従ったりしないでください。一致する提出物が存在しない場合は、レポートをアカウント侵害の証拠として扱うのではなく、未承諾または偽造の可能性があるものとして調査します。
修正を適切なレイヤーに割り当てます
アドレス指定ステータスは、メールボックスまたは連絡先の所有者に送信されます。ルートまたは接続の問題には、トランスポートの証拠が必要です。認証診断には、実際の関連メッセージ ID と受信評価が必要です。専門家が同様の故障を区別できるように、完全な診断情報を保管してください。
修正が承認された後、新しい試行を独自のキューおよびメッセージ ID に関連付けます。履歴レポートを後の結果で上書きしないでください。元の障害、修理、交換品の配送を、関連する個別のイベントとしてクローズします。これにより、再送信が成功した後に遅延レポートが到着した場合でも、正確なタイムラインが維持されます。
受信者固有のエスカレーションを準備する
- 相関関係: 受信者、時間、キューの証拠を使用して、レポートを正当な提出物と照合します。
- 発行者: Reporting-MTA を Remote-MTA および診断発行者とは別に保持します。
- 結果: アクション、ステータス、および元の診断コードを強制的に一致させることなく保持します。
- 所有者: 単にバウンスの送信者ではなく、実際の障害レイヤーを割り当てます。
- プライバシー: 必要なレポートフィールドのみを提供します。無関係な返されたメッセージの内容を転送しないでください。