要約

  • RFC 2047のencoded-wordは、許されたヘッダー位置で非ASCII文字を運び、読者向けの文字列を生成する。送信者の本人確認を行う仕組みではない。
  • 監査では、生のフィールド、構造解析、charsetの復号、メールボックス、署名対象、最終レンダリングを別々に残す必要がある。

二つの表示が食い違うと、つい「どちらが本当の名前か」と問いたくなる。しかし最初に確認すべきなのは、各ソフトウェアが何を入力にし、どこまで処理できたかである。対応するcharsetを持たない読者は符号の包みをそのまま出すかもしれない。別の読者は文字へ戻す。どちらの画面も、角括弧内のメールボックスや人間の権限を新たに証明したわけではない。

RFC 2047は1996年、Keith Mooreを著者として公開された。MIME文書群の一つであり、ASCIIを前提としてきたインターネットメールのヘッダーに、さまざまな言語のテキストを載せる方法を定めた。当時の経路には、行を折り直し、フィールドを並べ替え、珍しいが合法な構文を誤解するソフトウェアがあった。互換性を保ちながらSubject、コメント、人名を読めるようにするには、途中で壊れにくいASCIIの外形が必要だった。

encoded-wordの形は =?charset?encoding?encoded-text?= である。charsetがオクテットから文字への対応を示し、encodingには当初 Q と B がある。B はMIMEで使うBase64と同じで、Q はquoted-printableに似ており、アンダースコアを空白オクテットとして扱う。一単位は区切りを含め75文字以内、それを含むヘッダー行は76文字以内である。長い語句は複数単位に分けられる。

ここにあるのは転送と復元の仕様である。表示された人物についての認証欄はない。

復号より先に構文が決まる

encoded-wordを置ける場所は限定される。Subjectなどテキスト型のフィールド、コメント、そしてアドレスの前にある表示名のようなphrase内のwordで使える。一方、addr-spec、引用文字列、Received、Content-TypeやContent-Dispositionのパラメーターには置けない。

この制限は処理順序と結びついている。構造化フィールドはまずトークンへ解析され、その後、許された位置のencoded-wordが認識され、最後に表示用テキストへ戻される。復号結果に @ やコンマ、山括弧が見えても、その記号を使ってアドレスを再解析してはならない。画面上で同じ形をしていることと、メール構文上で同じ役割を持つことは別である。

RFC 5322では、name-addrの表示名とaddr-specが別の要素として記述される。表示名は人が読むための助けになり、addr-specはメールボックスを表す。同文書はFromの著者役割と、著者とは別の主体が実際に送信する場合のSenderも区別する。しかし、これらはメッセージ形式内の申告である。記法が正しいだけで、その人がアカウントを支配したことや、組織として指示する権限を持ったことまでは示さない。

クライアントがメールボックスを隠し、表示名だけの連絡先チップを置いても、プロトコル上の二項目が一つになったわけではない。

消える空白、残る来歴

隣り合うencoded-wordの間にある線形空白は、表示時に無視される。長い名前をヘッダーの都合で折り返しても、画面に余分な空白を挿入しないための規則だ。そのため、見える文字列は配送された行の逐語的な写しではない。

各単位は自己完結しなければならない。エスケープやマルチオクテット文字を一単位から次へまたいで分割できない。それでも異なる生データが同じ表示へ到達することはある。複数のcharsetが同じ文字を表し、QとBが同じテキストを運び、折り位置も異なり得るからだ。

逆に、一つの入力から異なる画面が生まれることもある。charset未対応、壊れたencoded-word、置換文字、エラー回復の差が原因になる。RFC 2047は、復号できない一単位のためにメッセージ全体の表示や処理を止めることを求めない。過去の画面を再現するには、受信データだけでなく、当時のパーサー、charset実装、エラー方針が要る。

復号は違いを隠して読みやすさを生む。監査は、その際に隠れた違いを必要な範囲で残す仕事になる。

UTF-8を直接置く場合

RFC 6532は、国際化メールを扱える環境で、多くのヘッダーフィールド本体にUTF-8を直接使えるようにした。NFCによる正規化を勧め、Unicodeの等価表現や紛らわしい見え方に関する安全上の問題にも触れている。RFC 2047の包みを通らない経路ができても、オクテット、コードポイント、グリフ、メールボックス、人物は同じ証拠にはならない。

実際の運用では新旧が混在する。直接UTF-8の新着、encoded-wordを持つアーカイブ、途中で変換するゲートウェイが同時に存在し得る。最終表示だけを保存する観測基盤は、どの経路を通り、どこで置換や正規化が起きたかを説明できない。

署名の責任主体は表示名ではない

RFC 6376のDKIMは別の証拠を作る。本文と署名者が選んだヘッダーフィールドをcanonicalizeし、署名ドメインの鍵で検証する。成功すれば、対象データが選択された規則の下で保たれたことを示せる。全可視フィールドが署名されたとは限らず、復号後の個人名を検証済みの人物へ変えるものでもない。

認証マークを表示名のすぐ横に置くUIは、二つの結果を視覚的に結合する。その結合を検証するには、どのFromが対象だったか、署名フィールド一覧、canonicalization、署名ドメイン、解析済みメールボックス、encoded-wordの認識位置、最終表示を追える必要がある。

正しく署名された入力と正しく復号された名前は、同時に成立する別々の事実である。

表示の領収書を作る

必要な記録は、観測点と保護された生フィールドのハッシュから始まる。フィールド順、折り返し、改行、パーサーとデコーダーの版、トークン境界、encoded-wordと認識した位置、charset、QまたはB、復号結果と置換方針を残す。得られたコードポイント、正規化、文字方向・スクリプト警告を記し、表示名とaddr-specを別欄にする。

DKIMについては、対象ヘッダー、canonicalization、検証結果、署名ドメインを並べる。最後に初めて、表示文字列、UI言語、フォント代替、警告状態を書く。原文、ソフトウェア版、表示条件がなければ、見慣れた名前で穴を埋めず「再現不能」とする。

メールヘッダーは個人情報を含み得る。領収書という考え方は無期限保存を正当化しない。最小化、アクセス制御、判断に比例した保存期間が必要である。

Keith MooreのIETF Datatracker記録には多数のRFCが掲載されている。University of Tennessee ICLが公開する2008年の歴史記事と肖像は、1991年から2007年まで同大学で研究職にあったこと、1990年からIETF標準化活動に参加したことを記す。これは現在の肩書ではなく、日付のある経歴である。ここで重要なのは、Mooreが一人でMIMEを発明したという物語ではない。RFC 2047が、読める文字と証明できる送信者の間に線を残したことである。

出典