要約

  • RFC 2034は、ほぼすべての2xx・4xx・5xx応答の人間向けテキスト先頭にclass.subject.detailを置く。拡張コードのクラスは、通常のSMTP応答クラスと一致しなければならない。
  • 対応サーバーは、クライアントがEHLOを使わなくてもコードを送る。要求も拒否もできない設計は、後続拡張の一般原則ではなく、限定された互換性上の例外である。
  • コードは機械分類、再試行、ローカライズを助けるが、一回の交換でサーバーが申告した分類しか証明しない。根本原因、最終配送、閲覧、方針の妥当性は別の証拠を要する。

メール運用で厄介なのは、エラー文が読めないことだけではない。同じ550の後に、存在しない宛先、転送拒否、アクセス方針といった異なる説明が続く。人なら文脈を読めるが、機械が製品ごと、言語ごとの自由文を解析すれば、診断規則はすぐに壊れる。

1996年10月のRFC 2034は、通常の三桁コードと説明文の間に小さな構造を置いた。従来の応答は残し、説明文の冒頭にクラス・主題・詳細の三要素を加える。大まかな制御は従来コード、細かな分類は拡張コード、具体的な説明は自然言語が担う。

二つの機械信号を矛盾させない

拡張名はEnhanced-Status-Codes、EHLOキーワードはENHANCEDSTATUSCODESで、引数も新しいSMTP動詞もない。変更点は既存の応答の内側に収まる。

クラスは2・4・5、主題と詳細はそれぞれ一桁から三桁である。2xxには2.X.X、4xxには4.X.X、5xxには5.X.Xを組み合わせる。同じ応答が一方では一時失敗、もう一方では永続失敗を名乗ることは許されない。

この整合性により、受信側は自然文を検索せず、同じ大分類に属する異なる問題を分けられる。運用集計はサーバー製品の文体に依存せず、画面はコードから日本語の説明を出し、原文を証拠として保持できる。

ただし、整った組合せは内部整合性であって外部真実ではない。550 5.1.1は、そのサーバーがその時点で宛先メールボックスの永続的問題を申告した事実を示す。遠隔データベースの状態や方針決定者、別経路の結果までは監査しない。

適用範囲の外側を欠落と呼ばない

対象は2xx・4xx・5xxの各応答行だが、最初の挨拶とHELO/EHLOへの応答は除外される。3xxも明示的に対象外である。RFCの会話例で、本文送信を促す354に拡張コードがないのは正しい。

したがって監視には直前のコマンドとセッション位置が必要になる。数字だけを切り出し、拡張コードの有無を数えれば、仕様上の例外と実装不良を混同する。

例に並ぶ2.1.0、2.1.5、5.1.1、5.7.1、2.6.0、2.0.0は、名前空間が会話の各段階で働くことを示す。しかし「メッセージを受理した」という状態遷移から、受信箱への配置、端末での表示、利用者の閲覧までは導けない。

EHLOを使わない相手にも送る

RFC 2034の異例な点は、実質的なオプトインがないことだ。対応サーバーは、クライアントがEHLOを用いたかにかかわらず拡張コードを付ける。要求する命令も、受信を拒む命令もない。

互換性は変更を置く場所で確保された。旧クライアントはもともと応答テキストを受け入れる必要があり、追加トークンも文章の一部として扱える。作者は当時のSMTPエラー実装の不備を踏まえ、より理解しやすい分類を全クライアントへ渡す価値があると判断した。

同時にRFCは、この方法を極めて特殊な例と明記する。将来の拡張が、サーバーの告知とクライアントの有効化なしに対話を大きく変える根拠にはできない。交渉なしで安全なのは、既存構文の中に変更が封じ込められ、状態機械を別物にしないからである。

複数行でも申告は一つ

応答が複数行に続く場合、各行のテキスト先頭には同じ拡張コードが必要になる。例の二行の551は、ともに5.7.1を持つ。通常のSMTP規則も、全行で同じ三桁コードを要求する。

繰返しにより、ログが行単位で処理されても分類を失いにくい。一つの応答が途中で別の原因カテゴリへ変わることも防げる。説明文は補足できるが、宣言された結果は一つである。

一方、説明が詳しいほど情報は漏れる。RFC 2034のSecurity Considerationsは、追加情報がサーバーについての情報を増やし、保護の回避に役立つ可能性を認める。内部ホスト名、アカウントの存在、転送経路、フィルター規則や閾値は、診断欄に入れただけで安全にはならない。

必要なのは分類の一貫性と開示の最小化である。遠隔の相手が行動できる説明は残し、内部の意思決定経路まで渡さない。

コードから言えること、言えないこと

4.X.Xを一時失敗キューへ置き、5.X.Xで自動再試行を止めるのは合理的なローカル判断である。主題と詳細により、アドレス管理、容量、セキュリティ、設定の担当へ振り分けられる。継続観測は、リリース後に相手の分類が変わったことも示せる。

しかしコードは、内部検索が失敗した理由、フィルターの正しさ、翌日の方針、経路上での保存を証明しない。成功クラスも同様で、サーバーが受理した事実と、利用者が読んだ事実の間には複数の実行段階がある。

RFCの例は後に通知を組み立てるが、報告MTAが煩雑さを減らすため一部の診断欄から拡張コードを省いたとも記す。ライブ応答、キュー記録、後発通知、利用者向け要約は別の成果物であり、変換ごとに情報が失われ得る。

RFC 5248によるIANA登録は、コードの衝突を避ける共通語彙を整えた。登録は個々の診断を保証しない。文書、実装、通信、最終結果を別の現実層として扱う必要がある。

運用証拠には、相手、時刻、コマンド、通常コード、拡張コード、全文、行境界、解析結果、ローカル判断を結び付ける。構文と整合性は決定的に検査できる。原因と結果は独立資料で補う。RFC 2034の価値は、共通の形を与えたことであり、形の外側まで真実と宣言したことではない。

出典