要約

  • RFC 3191 は電話番号の最小表現をインターネットメールのローカル部に置いたが、サービス選択子、番号、修飾子を解釈できるのは @ の右側にあるドメインを担当する MTA だけだとした。
  • 構文は実行証明ではなかった。見やすさのための区切りは無視され、未知の修飾子は実行しなくても保存され、複数のサブアドレスは複数の受信者となり、DNS や SMTP の成功も加入者の身元や端末への到達を保証しなかった。

文字列が命令に見えても、権限までは付いてこない

メールと電話をつなぐゲートウェイが広がると、音声、ファクス、短文メッセージの宛先をメールアドレスに書く方式が乱立した。数字をどう並べるかだけなら難しくない。より重大なのは、どのシステムがその数字を電話上の行為へ変換してよいのか、という問いだった。

RFC 3191 の答えは最小限だった。ローカル部にはサービス選択子、等号、電話番号の表現を置き、必要なら登録済みの修飾子を続ける。@ の後にはゲートウェイのドメインを置く。

一見すると VOICE=+... のような左辺は自己説明的である。しかしメールの原則では、あるドメインのローカル部を解釈するのは、そのドメインを扱う MTA だけである。途中の中継サーバーは文字を読めても、電話の意味を実行する権限を持たない。右辺が解釈者を選び、左辺がその解釈者への入力になる。

この境界により、番号の形が世界共通の身元表明になることを避けられた。番号は加入者を証明せず、ドメインは番号の実在や利用可能性を保証しない。アドレス全体が示すのは、特定のゲートウェイへ解釈を依頼することまでである。

最小構文は電話帳でも到達性検査でもなかった

グローバル形式は + から始まり、数字が続く。読みやすくするためにピリオドやハイフンを含めることもできたが、適合実装はそれらを無視し、送信側は生成を避けるべきだとされた。表示上のまとまりが違っても、処理対象となる最小番号は同じになり得る。

一方、先頭のプラス記号は単なる装飾ではない。これはグローバル形式のために予約された。ローカルまたは私設のダイヤル方式をゲートウェイが扱う余地はあっても、その形式がプラスを借りて世界的な番号を装うことはできない。

サービス選択子には英数字とハイフンを使い、大文字と小文字を区別しない。仕様中の VOICE、FAX、SMS は形を説明する例であり、実在する有効な宛先の一覧ではない。構文に通ることは、番号の割り当て、サービス契約、接続可能性、端末応答のどれも証明しない。

RFC 3191 は電話番号体系を全面的に正規化するのではなく、ゲートウェイへ渡す最小表現に責任を限定した。

理解できない修飾子にも、消してよいとは書かれていない

番号の後ろには、スラッシュ、名前、等号、値からなる修飾要素を追加できた。後続の仕様はこれを使って、共通の最小文法を作り直すことなく、サービス固有の情報を表現できる。

最小機能しか持たない実装は、対応していない修飾子を実行上は無視できる。しかし RFC 3191 は、受け取ったすべての修飾要素を保存するよう求めた。無視するとは「ここでは扱えない」という局所的な判断である。削除するとは、後続のすべての処理者から意味を奪う全体的な判断である。

保存されていれば、後段にいる正当な解釈者が元の意図を回収できる。消されれば、どこで誰が情報を捨てたのかさえ分からない。

サービス選択子と修飾子の追加には登録も必要だった。第三者が独立実装できる恒久的な仕様を示し、修飾子には使用可能な文脈を定めることもできる。登録簿は共有語彙を統治するが、個々のゲートウェイがその機能を実装済みだとは保証しない。

古い変換の痕跡を受け入れても、標準形にはしなかった

完成したオブジェクトは、メールの引用規則に従う addr-spec であり続けた。電話構造の前後にスラッシュが付く形も受信側は認めなければならなかった。X.400 など別のゲートウェイ経路を通った際に残る可能性があったからだ。

ただし新しい送信者はそのスラッシュを作るべきではなく、変換時に取り除くこともできた。過去の痕跡を読めることと、未来にも同じ痕跡を増やすことは別である。

RFC 3191 自体も RFC 2303 を置き換えた。PSTN の Public ではなく GSTN の Global という説明を採用し、電話事業が一つか少数の公共事業者に収まらない現実を反映した。その一方、既存実装を壊さないため古い ABNF 変数名の一部は残した。制度を説明する言葉は直しても、配備済みの識別子を美観だけで変更しなかった。

一つの電話メールボックスが複数のメール受信者になる

電話サービスでは、同じ番号に複数のサブアドレスを結び付けられる。メールでは受理、失敗、再試行を受信者ごとに管理する。そこで RFC 3191 は、複数のサブアドレスがある場合、複数の pstn-email 要素を作るよう定めた。

利用者向け画面は一度に入力させてもよいが、MTA へ渡す際には別々の受信者でなければならない。この変形によって、あるサブアドレスだけが受理され、別のものが拒否された場合にも結果を区別できる。

受信者を分けることは電話側の成功を約束しない。SMTP が二件とも受理しても、ゲートウェイが片方だけ解析することがある。ゲートウェイが受理しても、端末が応答しないこともある。メールの封筒、ゲートウェイへの引き渡し、交換網への投入、最終機器の反応にはそれぞれ別の証拠が必要だ。

DNS が選んだのはメール経路であって電話上の真実ではない

右辺ドメインはゲートウェイへのメール経路を決める。このため RFC 3191 のセキュリティ節は DNS の操作を重視した。侵害されたサーバー、偽造応答、汚染された追加情報により、メッセージを敵対的な MTA やゲートウェイへ迂回させられる。

権威ある DNS 応答を検証すれば、経路選択への信頼は高まる。しかしその証明は電話側まで自動的には延びない。正しいゲートウェイでも、誤ったソフトウェア、古い番号情報、ポリシー拒否、電話網への経路欠如があり得る。実在する番号でも、送信者が想定した人物のものとは限らない。

監査では、利用者が送った原文、MTA が用いた DNS 応答、SMTP 受理、ゲートウェイの解析判断、交換網へ渡した命令、最終受領通知を分けて残す必要がある。「メールが通った」という一文にまとめれば、どの境界で権限が移ったのかが消える。

共通形式は結果を所有しようとしなかったから続いた

RFC 2846 はローカルダイヤル、発信後シーケンス、サブアドレス、受信者詳細を含む、より豊かな上位形式を定めた。RFC 3192 は最小枠組みをファクスへ具体化した。それでも RFC 3191 の一般形が万能な実行機構になったわけではない。

歴史的な成果は小さく、しかし重要だった。異なるサービスが一つの短い封筒と登録制の拡張方法を共有できた。中継系は権限のない意味を解釈せずに運べた。ゲートウェイは登録語彙を理解しながら、構文上正しい宛先すべての実在を保証せずに済んだ。

@ の左には電話らしい表現があり、右にはその解釈者を選ぶドメインがあった。最終結果はどちらの文字列にも含まれていない。相互運用は、見た目ほど多くの権限を各層に与えなかったことで成立した。