拡張ステータス コードは構造化された手がかりであり、完全なインシデント レポートではありません。 「5.7.1」では、調査をセキュリティまたはポリシーに絞り込むことができますが、ポリシーの所有者、影響を受けるルート、または正しい構成変更を単独で特定することはできません。トラブルシューティング中は、完全な診断情報をコードの横に保管してください。
3 つのコンポーネントをすべて読む
RFC 3463 、クラス、件名、および詳細コンポーネントを含む拡張ステータス コードが定義されています。このクラスは、成功、永続的な一時的な失敗、永続的な失敗を区別します。サブジェクト カテゴリは、アドレス指定、メールボックスの状態、ルーティング、セキュリティまたはポリシーなどの領域を区別します。詳細により、その主題内の条件が絞り込まれます。通常の 3 桁のSMTP応答は証拠の一部として残ります。 RFC 3463.
最後の番号をグローバル エラー識別子として扱わないでください。意味は、完全な拡張コードと、該当する登録またはプロバイダーのドキュメントによって異なります。受信システムは、拡張コードなしで有用な散文を返すこともできます。基本クラスと拡張クラスに一貫性がないように見える場合は、ログを黙って書き換えるのではなく、正確なバイトを保存してプロバイダーの動作を調査してください。
SMTP応答を配信レポートから分離する
SMTP応答は会話中に発生します。配信ステータス通知では、後で結果を報告したり、複数の受信者を説明したりできます。 RFC 3464では、最終受信者、アクション、ステータス、リモート MTA、診断コードなどのフィールドが定義されています。受信者ごとのブロックを個別に読み取ります。 1 回の失敗が、すべての受信者が失敗したことを証明するものではありません。 RFC 3464セクション 2.
アクションとステータスはさまざまな質問に答えます。アクション: 失敗はレポートを意味します MTA その受信者に対する試行を停止しました。ステータス: 4.2.2 では、再試行がすべて終了した後でも、一時的なメールボックスがいっぱいになる原因を説明できます。失敗に加えて 4.xx ステータスは DSN 内で有効であり、一貫性のないSMTP応答ではありません。たとえば、これらのフィールドを持つ期限切れのアイテムは、容量が戻っただけで自動的に再開されません。置換を承認する前に、実際のキューを確認してください。見る RFC 3464セクション 2.3.3.
人間が読めるバウンス件名はトリアージに役立ちますが、決定的なフィールドが省略される可能性があります。可能であれば、機械可読レポートまたは送信ログを取得します。レポート サーバーをリモート サーバーから分離し、レポートのタイムスタンプと失敗したSMTPコマンドのタイムスタンプを区別します。
仮想受信者ブロックを読み取る
送信ログに、 missing@example.testの RCPT TO とその後に 550 5.1.1 が記録されているとします。例示的な DSN 受信者ブロックには、Final-Recipient: rfc822; を含めることができます。 missing@example.test 、アクション: 失敗、ステータス: 5.1.1、リモート MTA: dns; mx.example .test および診断コード: smtp; 550 5.1.1 そのようなユーザーは存在しません。これらは作成されたフィールド値であり、実行されたトランザクションや完全なMIMEレポートではありません。
失敗したアクションはこの受信者にとって最終的なものですが、診断ではアドレス指定が指示されます。アドレスが利用できない理由や、他の受信者に何が起こったのかは明らかにされません。これらの回答は、独自のブロックと信頼できるログから取得します。最終受信者、アクション、およびステータスは受信者ごとに必須のフィールドです。リモート MTA と診断コードは条件付きまたはオプションです。彼らの不在は、拒否するホストやエラー テキストをでっち上げる許可を与えるものではありません。
不明な登録内容については、最新の情報を参照してください。 IANA拡張ステータス レジストリ そして引用された仕様、そしてプロバイダーの現在の説明。 RFC 3463 、以降のすべてのコードの完全なリストではなく、フレームワークを提供します。
コードをテスト可能な仮説に変える
宛先コードについては、意図する宛先と受信システムの動作を確認してください。ルーティング コードについては、失敗したネクスト ホップとルート構成を検査します。セキュリティ コードまたはポリシー コードの場合は、指定された要件とその所有者を特定します。優先DNS変更から始めて、すべての応答をそれに対するサポートとして解釈することは避けてください。
1 つの仮説、それが予測する証拠、および承認された最小のテストを記録します。修正されたメッセージは、関連するルートおよび受信者クラスで元のメッセージと比較される必要があります。矛盾した結果を元の説明に押し込むのではなく、有用な証拠として保存します。エスカレーション パケットには、タイムスタンプ、正確な応答、影響を受ける範囲、およびテスト済みの変更を含める必要があり、メッセージの内容と個人データは最小限に抑えられます。コードの検索は診断の始まりであり、完了ではありません。
有用なエスカレーション パケットを作成する
- ID: メッセージとキューの識別子、失敗したエンベロープ受信者、および影響を受けるスコープを保持します。
- タイムライン: 提出、失敗した試行、および到着レポートを個別に記録します。
- 診断: 正確なSMTP応答、コマンド ステージ、および受信者ごとの DSN フィールドが含まれます。
- 所有権: 報告システムと拒否システムを区別し、それぞれの証拠を示します。
- 次のステップ: 検証可能な原因を 1 つ、許可された最小限のチェックと、矛盾する証拠をすべて述べます。個人データを最小限に抑えます。