要約

  • RFC 2368 は mailto: を複数の宛先、ヘッダー、短いプレーンテキスト本文を含むテンプレートへ拡張したが、URL の解決は即時のネットワーク通信を要求しなかった。
  • クライアントは危険なフィールドを拒否でき、復号後の全内容を示して承認を求めるべきだった。リンク、クリック、入力済み下書きは送信や到着の受領証ではない。

Web のリンクは、押せば遠隔の資源へ進むものに見える。mailto: は違った。押した結果がローカルの作成画面だけで終わり、メール網には何も出ないことが正しい動作だった。

RFC 1738 の単純なアドレス形式に対し、RFC 2368 は ? の後へ名前と値を置き、複数項目を & でつないだ。特別な body は最初の text/plain 本文を表した。購読コマンド、資料請求、アーカイブへの返信、CC 付きメッセージをページ側で準備できた。

しかし、準備と実行の所有者は別である。ページ作者は URL を書く。パーサーはエスケープされたオクテットをフィールドへ戻す。メールクライアントは安全方針を適用する。利用者は表示結果を承認する。その後の投稿受理、転送、メールボックスへの配送、閲覧、コマンド実行には別のシステムと別の記録が要る。

符号化は単なる表記ではなかった。?、=、& は構造記号なので、データとして使うときはパーセント符号化する。空白は %20、本文改行は %0D%0A、文字としての % は %25 になる。HTML 内では区切りの & を & と書く。ソース、解析済み URL、表示された下書きは同一文字列ではない。復号順序を誤れば宛先や境界が変わる。

1998 年の国際化制約も明瞭だった。未符号化の 8 ビット文字は禁止され、MIME encoded-word はヘッダー値では使えても body では使えない。変数置換もないため、クリックした人のアドレスやローカル情報に依存する署名を静的リンクへ安全に埋め込めない。これは小さなテンプレートであり、汎用プログラムではない。

文法が任意のヘッダー名を受け入れても、クライアントに採用義務はなかった。危険なら作成自体を拒否し、安全な一部だけを残してよい。Subject、Keywords、Body は有用とされた一方、From、Bcc、経路や MIME に関わる項目は特に疑うべきだった。外部文書は提案できても、ローカルの実行方針を上書きできない。

送信前の開示はさらに重要だった。クライアントは URL が指定したヘッダーを含む完全な復号結果を見せ、電子メールが送られることを明示し、承認を求めるべきだとされた。隠れたテンプレートは第三者へ身元を知らせ、料金を生み、違法な文面や損害を与える命令を利用者名義で送る恐れがある。

証拠は段階別に読む必要がある。URL の存在は提案を証明する。クリックは画面の起動までしか示さない。下書きはクライアントが一部の値を受け入れたことを示す。送信操作、サーバー受理、配送、閲覧、相手側の処理は、それぞれ独立に確認しなければならない。

RFC 6068 は UTF-8 を使ったパーセント符号化や重複フィールドの扱いを整え、RFC 2368 を置き換えた。それでも URI はメッセージのテンプレートであり続けた。文字が正しく届く規則と、人が送ることを認めた事実は同じではない。

RFC 2368 の歴史的な設計は、入力の省力化と権限移譲を分けた点にある。リンクは文章を書けたが、利用者の署名にはなれなかった。

出典