要約

  • 2026年9月10日に投稿されたdraft-ietf-mailmaint-smtputf8-syntax-05は、許容する文字クラスの列挙をPRECIS IdentifierClassへの参照に替え、該当する文脈規則への適合を求めた。
  • 新しい例は、表示上は空に見えるU+3164 HANGUL FILLERと、直前のアラビア文字を伸ばすU+0640 ARABIC TATWEELを不許可とする。
  • 文字列が構文検査を通っても、メールボックスの存在、利用者の本人性、支配、SMTPUTF8対応経路、最終配送は証明されない。
  • 現行文には引用符で囲まれた空白とアドレス記号の関係に読みにくい箇所が残る。実装側で黙って補完せず、版と解釈を記録する必要がある。

ログには同じ、バイト列には別

復旧窓口で二つの利用者記録が衝突したとする。担当者の画面には同じ管理者用メールアドレスが並ぶ。一方のローカル部だけにU+3164が入り、そのフォントでは幅を持たない。人が読んだ結果は同じでも、比較したUTF-8列は同じではない。

登録画面は受け入れ、認証基盤は拒否するかもしれない。検索索引が文字を落とし、原本データベースが保持することもある。ログがレンダリング済みの文字だけを残せば、どの層が何を判断したか後から証明できない。

第05版はU+3164を、何も表示されないため通常のASCIIアドレスと同じに見える例として追加した。U+0640も除外する。ARABIC TATWEELは一般カテゴリ上は文字だが、直前の文字を引き伸ばす働きを持ち、挿入回数によって見た目の綴りを増やせる。

Datatrackerでは、文書はMail Maintenance WGのActive Internet-Draftで、目標はProposed Standardである。履歴は9月10日の第05版を記録する。現時点で確認できるのは提案の更新であり、RFC化、製品採用、不正利用の発生ではない。

表の写しから判定手順へ

第04版はRFC 8264のA、H、K、Fという区分とアドレス記号を本文に列挙していた。第05版は、PRECIS IdentifierClassが有効とするコードポイントだけを認め、文脈規則が必要ならそれも満たす、と書き換えた。

重要なのは参照先が単なる許可表ではない点だ。RFC 8264のIdentifierClassには、有効、文脈規則が必要、不許可、未割当という処置がある。結合制御文字のように周囲を調べなければ結論が出ないものを、Unicodeの大分類だけで許可してはならない。

IdentifierClassは、利用者名などネットワーク上の対象を識別・参照する文字列を想定し、表現力より安全性を優先する。伝統的な文字と数字、印字可能ASCIIを認める一方、古いHangul Jamo、制御文字、不可視属性、空白、互換分解される文字などを排除する。ただしPRECISのクラスだけで全処理は決まらない。利用するプロファイルは、幅、追加マッピング、大文字小文字、正規化、方向性を定義する責任を持つ。

旧版と新版は同じ標準群を参照している。したがって、05が許容集合を全面的に反転したと読むのは正確でない。変更の核は、実行可能な分類の所在と、文脈検査を必須の段階として示したことにある。

一般カテゴリだけではU+0640を裁けない

RFC 5892はU+0640を明示的な例外表に置き、DISALLOWEDとする。通常のプロパティ計算だけならPVALIDになり得るためだ。つまり「UnicodeではLetter」というログは、識別子として許可した根拠にならない。

公開されている作者テストには、双方向制御、全角互換文字、結合型の古いHangul Jamo、対応する合成済み音節なども入る。これは判定を再現する材料になる。しかしテストに合格した一つのライブラリは、登録、ログイン、復旧、アドレス帳、エクスポート、SMTPエンベロープが同じ版で動くことまで保証しない。

第05版の第3規則は、ASCIIを除外して数えたとき一つのアドレスに複数スクリプトを含めない、というものだ。Unicode Standard Annex #24がここでいうScriptプロパティを定義する。この線引きはアドレス互換性のための提案であり、多言語の人名や組織を評価する物差しではない。

引用符内の空白は未解決のまま

現行テキストの第2規則は、IdentifierClassが有効とするコードポイントと、引用符内の空白だけを含める、と文字どおり読める。一方、直後の例はドット、スラッシュ、at記号を別に挙げる。公開ソースにも同じ表現がある。

誤記なのか、上位のmailbox構文を前提にした省略なのか、次版待ちの文章なのかは、公開記録だけでは決められない。区切り記号はローカル部とドメイン部を分けるため、文字クラスと構文規則を混同すべきではない。実装者が独自に直すなら、その解釈を標準そのものと称さず、テストと版情報に残すべきだ。

通るアドレスは、正しい人物ではない

RFC 6532はメールのヘッダーやアドレスでUTF-8を直接扱えるようにした。今回の草案は、その範囲の中で相互運用しやすいアドレス文字列をさらに絞ろうとしている。どちらも、人や組織の権限を認証する仕様ではない。

構文が正しくてもメールボックスが存在しないことはある。確認メールへの応答はある時点の支配を示しても、法的本人性を決めない。一つのSMTPホップが対応しても、経路全体の対応や配送を示さない。不許可文字を入力した人も、不可視コードポイントを知らずにコピーしただけかもしれない。

BTWの既存SMTPUTF8史は、国際化ローカル部に一般的なダウングレードがなく、配送経路が値を保持する必要を扱った。本稿の対象は、その前段にある受入判定だ。文字准入と配送能力は別々に失敗する。

判定理由を消さない受入レシート

監査可能なレシートには、入力UTF-8バイト列とコードポイント順序をまず残す。次にmailbox文法上の位置、各非ASCII文字のIdentifierClass処置、文脈規則と結果、スクリプト計算、マッピング、大小文字、正規化、方向性の方針を結び付ける。

さらにUnicode/PRECISデータ版、検証器ビルド、呼出画面、時刻、最終動作、利用者の修正経路が要る。運用画面では可読表示とエスケープ表現を併記し、原入力は保護された証拠として扱う。画像ログだけに戻してはいけない。

これはDaniel Kadeによる編集上の提案で、IETFの要件ではない。目的は各社のメールボックスポリシーを統一することではなく、複数の入口が同じ入力を同じ規則で扱ったか説明できるようにすることだ。

情報源