要約

  • RFC 3939 は、電話網が着信側に提示した番号と名前を保存する Caller-ID、Caller-Name ヘッダーを定義した。
  • それらは本人認証ではない。国際番号の切り詰め、内線番号の域外転送、文字コードの不一致によって、もっともらしい誤情報になり得た。

From に電話を偽装させない

応答できなかった通話を Internet Mail の保管庫に置くとき、発信者のメールアドレスが分からない場合がある。RFC 3801 は返信不能な電話応答メッセージに non-mail-user を認めていた。しかし電話番号を From の表示名や人工的なアドレスへ押し込むと、メール上の送信者と電話網の観測値が混ざる。

2004年12月の RFC 3939 は置き場所を分けた。Caller-ID は電話システムが供給した数字、Caller-Name は提示名を保持する。これは由来を示すための設計であり、話者の本人性、番号の所有権、通話の正当性を証明する仕組みではない。

文脈がなければ unknown

番号欄は数字だけで構成される。社内通話なら内線だけでもよく、国際通話なら E.164 の国番号以下を最大15桁で保持する。任意の NumberingPlan は unknown、local、e164 を示すが、省略時は unknown である。

local の意味は、そのボイスメールを保存したシステムのドメイン内に限られる。RFC 3939 自身も、ここで扱う値を発信可能な電話アドレスとは定義しなかった。RFC 2806 がローカル電話 URL に文脈を要求し、RFC 3191 がメール内の国際 GSTN アドレスに + を予約したことは、行動可能なアドレスに追加情報が必要だったことを示す。

成功した配送が、誤った折り返しを生む

仕様は、国際番号が10桁へ切り詰められる実装を警告した。アイルランドの番号から先頭が失われると、残りが北米の番号に見える例を挙げている。構文エラーにはならず、むしろ無関係な相手への発信に成功し得る。数字の個数だけを見る検査は意味の破壊を見逃す。

内線転送では逆の問題が起きる。社内で有効な短い番号は社外では届かず、それでも企業の私設番号計画を露出する。ヘッダーが一字も変わらず届いたことは、解釈権が移った証拠ではない。

名前にも同様の境界があった。複数の電話信号文字セットに対し、仕様は ASCII を基本とし、必要なら RFC 2047 で原言語の文字を符号化できるとした。受信側が同じ選択肢を理解しなければ表示名は誤る。事業者が15文字へ短縮する場合もあった。

非通知情報は、事業者間の完全な詳細ではなく、着信者が画面で見た Private Name などを保存する方針だった。ただしメール化すると、番号は転送され、長く残る。クライアントが表示しなければ、利用者はそのメタデータの存在すら知らない。

Date も電話網の時刻か保管システムのローカル時刻かを実装が選べた。出所を残さなければ、タイムスタンプだけで通話時刻を断定できない。

RFC 3939 の意義は、発信者表示を強い身元証明に見せなかった点にある。観測値を運ぶ欄を作りながら、番号体系、文字環境、開示範囲、折り返し結果は別の証拠だと読める仕様だった。