要約

  • RFC 5248 は SMTP 拡張状態コードを三つの表に分け、公開仕様、申請者、変更管理者を結び付けることで、語彙の衝突を抑える仕組みを作った。
  • その登録は意味の所在を示すが、サーバーの診断、クライアントの解釈、再試行の妥当性、メールの最終的な配達結果を保証しない。

状態コードは途中の発言である

一通のメールが最終的な宛先へ進むまでには、複数の機械が判断する。送信側サーバーが応答を受け、キューが次の行動を決め、別のサーバーが受理し、さらにメールボックスやアプリケーションが処理する。拡張状態コードはその途中で発せられた構造化された発言である。

ところが運用画面では、この発言が「根本原因」や「最終結果」という名前に置き換えられやすい。IANA 台帳に存在することが、その置き換えを正当化するようにも見える。RFC 5248 を読むと、台帳の目的は別のところにあることが分かる。

RFC 3463 は拡張可能なコード空間を設計したものの、新しい値を登録し追跡する明示的な手順を持たなかった。その結果、相反する定義が現れた。BCP 138 である RFC 5248 は、この衝突を避ける登録制度を設け、RFC 4468 や RFC 4954 など既に語彙を追加していた文書も更新した。解決したのは命名の調整であって、配達観測の欠落ではない。

三つの表が意味の持ち主を分ける

コードは「クラス・サブジェクト・詳細」の三段で表される。RFC 5248 の台帳も、クラスのサブコード、サブジェクトのサブコード、列挙済み状態コードという三つの表に分かれる。列挙表ではサブジェクトと詳細を組み合わせ、クラスにはワイルドカードを残す。定義仕様が認めるなら、同じ条件を複数のクラスで使えるからである。

各登録にはコード、要約または例文、説明、参照文書とその標準化状況、申請者、変更管理者が記録される。列挙項目には、関連する基本 SMTP 応答も加わる。これは、意味がどこから来て誰が直せるのかを示す来歴情報である。

基本応答との関連は非排他的だ。三桁のコードが一つ掲載されていても、別の組み合わせを禁止することにはならない。欄には Any や Not given も入り得る。監視製品がこの欄を一対一の許可表として実装すれば、RFC が残した幅を勝手に削り、正しい通信まで異常と判定しかねない。

唯一の未定義コード X.0.0 は、応答のクラスしか分からない場合に使う。これは「詳細は不明」という情報を保つための値であり、原因を推定してよいという許可証ではない。分からないものを分からないまま保存することも、相互運用性の一部である。

登録審査と実装監査は違う

新規値には Specification Required が適用される。RFC 5248 は、標準化過程外の仕様も容易に入手できることを求め、主眼を混乱と衝突の回避に置いた。現在の方針を説明する RFC 8126 では、恒久的に公開される仕様と指定専門家による審査を組み合わせる。専門家は明確さ、安定性、技術的品質を検討する。

しかし専門家が審査するのは、共有できる定義である。稼働中のメールキューを調査するわけではない。特定の受信者で障害を再現せず、全サーバーの送出ロジックや全クライアントの解析器も認証しない。良質な登録コードが誤った場面で送られることはあり、現実の障害が粗すぎるコードで報告されることもある。

変更の権限も限定されている。標準トラックの登録は通常、その標準を更新して変更する。非標準の登録は、記載された変更管理者が扱う。通常の修正は説明や参照先を直すもので、番号や例文を静かに別用途へ流用するものではない。衝突解消のため、IESG には例外的な変更権限が残る。

初期登録には、公開 RFC から採った値だけでなく、公開仕様がないまま業界で使われていた値も含まれた。セキュリティ関連のいくつかは IESG 管理で収録された。また「Trust Relationship Required」は、以前の X.7.8 の使用から X.7.14 へ移された。台帳は共通語彙の住所を修正できるが、全実装が移行済みか、過去ログをどう解釈すべきかまでは証明しない。

クラスは時間を固定しない

RFC 3463 では、クラス 2 は配達状況通知における成功、クラス 4 は将来の試行で成功する可能性がある持続的な一時障害、クラス 5 は通常、メッセージか宛先の変更を必要とする恒久障害を表す。この区別は自動処理に欠かせない。

それでも、クラスは未来の保証ではない。RFC 5321 はクライアントに、説明文ではなく応答コードに基づいて動くよう求める。4yz なら条件に応じて後で再試行でき、5yz なら同じ要求を変更せずに繰り返すべきではない。同時に、恒久的に見えた状態が後で訂正され得ることも認めている。

したがって 4.x.x は成功予約ではなく、5.x.x は永遠の不可能証明でもない。再試行制御には、メッセージと受信者の識別、試行回数、経過時間、応答したサーバー、構成変更、後続応答が必要だ。コードは方針への入力であり、時間軸そのものではない。

RFC 2034 は拡張状態コードを SMTP 応答で運ぶ方法を定め、RFC 5248 はその語彙を管理する。コードを選ぶロジック、受け取る解析器、保存するキュー、行動を決める自動化はそれぞれ別の制御面である。SMTP 上の受理より先にある、最終システムの受け入れやメールボックス処理も別に観測しなければならない。

正確さと公開量は同じ軸ではない

RFC 5248 のセキュリティ節は、詳細なコードが内部実装を漏らす可能性を指摘する。認証で「利用者が存在しない」と「パスワードが違う」を外部から区別できれば、攻撃者に有用な手掛かりを与える。各仕様は、サーバーが詳細を制限すべき場面を示す必要がある。

そのため、外部応答が一般的で、内部診断が具体的であることは両立する。これは必ずしも不整合ではなく、開示方針の結果である。監査では公開コード、内部コード、元の観測、開示ルールを別々に保存したい。外部の詳細が少ないことを診断不足と決め付けず、詳細が多いことを真実性の証拠とも扱わない。

証拠の階段を一段ずつ上る

最初に分かるのはコードが構文上読めることだ。次に、観測した版の台帳にその割り当てがあることを確認できる。その後も、サーバーが登録済み条件を主張したという段階にとどまる。基本応答との整合、コマンドと受信者を含む文脈の保存、サーバーログやキュー遷移による裏付けが必要になる。

さらに上には、正しいメッセージへの再試行、後続転送、宛先側の受理、メールボックスでの処理、人や業務への到達がある。下段の記録が上段の権限を自動的に得ることはない。登録済みコードは証拠の一部にはなるが、証拠列全体にはならない。

Lu Heng が示す running code と現実層の区別は、この分離を支える。台帳は記号を調整し、実装はその記号を使って動き、運用記録は実際の遷移を残す。どれも必要だが代替関係ではない。共有語彙を尊重する最善の方法は、語彙に与えられていない結果権限を背負わせないことだ。

情報源