要約

  • SMTPUTF8はエンベロープのメールボックス名とヘッダー値をUTF-8へ広げたが、各サーバーの能力広告が前提だった。広告するサーバーは8BITMIMEも提供しなければならない。
  • ドメインはIDNAのA-labelへ変換できるが、非ASCIIローカル部に一般的な同一名はない。非対応経路では、投稿時の権限ある変換、別経路、再試行、失敗のいずれかを選び、メールボックスを捏造してはならなかった。

表示された名前は配送先ではなかった

MIMEは表示名や件名にASCII外の文字を見せられた。しかしRFC 6530が区別するように、表示名はSMTPエンベロープから見えず、多くの用途でアドレスそのものではない。

IDNAは@の右側のドメインを国際化した。左側のローカル部は、最終配送システムが管理する名前のままASCIIに制限されていた。UnicodeドメインにはDNS用のA-labelがある。一方、ローカル部には同じメールボックスを保証する普遍的な翻字がない。置換先は存在しないか、別人かもしれない。

完全な国際化は表示機能ではなく、名前をそのまま保つ経路の問題になった。

中継途中の格下げという近道を捨てた

RFC 6530はRFC 4952を置き換え、実験的な中継時ダウングレード仕様を不要としてHistoricへ移すよう記録した。途中のリレーには、ASCIIの代替身元を作る権限も情報もなかった。

2012年2月の標準化文書は役割を分けた。RFC 6531はSMTP輸送、RFC 6532はUTF-8ヘッダー、RFC 6533は元の国際化受信者を保つ配送・開封通知を定義した。これは翻訳表ではない。エンベロープ、メッセージ、失敗証拠が同じアドレスを指す環境だった。

SMTPUTF8という一語は完全履行を意味した

サーバーはEHLOでSMTPUTF8を示す。IANA SMTPサービス拡張登録簿はパラメーターなしで国際化メールアドレス能力として記録している。

RFC 6531は、広告するサーバーに仕様全体への準拠を要求し、8BITMIMEの対応と広告も義務付ける。8BITMIMEは本文の高位ビットを保管する。SMTPUTF8はエンベロープの宛先と身元を含むヘッダーを拡張する。後者は八ビットクリーンな環境を必要とするが、前者を置き換えない。

クライアントは値を持たないSMTPUTF8パラメーターをMAIL FROMへ付けられる。エンベロープ、メッセージ、ヘッダーのどこかがこの拡張を必要とするという宣言である。区切り構文は残り、使える文字集合だけが広がる。

経路が到達性の条件になった

能力広告がなければ、国際化アドレスもRFC 6532ヘッダーも送ってはならない。後者が入れ子のMIME内にあっても同じである。同じメールボックスが、対応MXでは届き、非対応MXでは一時的に届かないことがあり得る。

別MXや再試行は、名前を変えるのではなく忠実に運べる道を探す行為だ。投稿代理には、利用者の管理境界で権威あるASCII別名を使うなどの裁量がある。しかしRFC 6531は変換方法を定義せず、通過中のリレーに翻字権限を与えない。

適法な変換も経路もなければ、拒否、適切な不達通知、再キュー、代替ホストを選ぶ。「経路が運べない」と「メールボックスがない」を混同しないために、失敗が必要になる。

UTF-8はフィールド値に入り、フィールド名には入らなかった

RFC 6532はSubject、アドレス、引用文字列、ドメイン、一部Message-ID構造へ直接UTF-8を認める。ヘッダーフィールド名はASCIIのままである。

行の上限は998オクテットになり、表示上の78単位推奨は文字数のまま残る。UTF-8では一文字が複数オクテットを占めるため、輸送容量と読みやすさが別の尺度になった。

正規化も中継に身元統合の権限を与えない。RFC 6532はNFCを勧め、綴りの差を失う場合のNFKCを避ける。ローカル部の意味を決めるのは最終配送システムである。

失敗通知は失敗した名前を保存した

RFC 6533はUTF-8アドレス型とORCPT・DSN向けの表現を定義し、七ビット環境で証拠を保つ形式も用意した。これは配送可能なASCIIメールボックスへの格下げではなく、元の受信者名を報告に残す符号化である。

SMTPUTF8とDSNを同時に広告するサーバーはRFC 6533を実装しなければならない。失敗した身元を失う通知は、運用上対応付けられないからだ。

能力は所有権ではない

SMTPUTF8は文字列を解析・輸送できることを示す。メールボックスの存在、所有者、見た目の似た名前の同一性、最終配送や安全な表示は証明しない。

ドメイン所有者はDNSを、最終システムはローカル名前空間を、送信元は明示した別名を管理する。リレーに許されるのは正確な輸送か明示的失敗であり、流れを保つための代役発明ではない。

出典と限界

枠組みはRFC 6530、SMTPはRFC 6531、ヘッダーはRFC 6532、通知はRFC 6533、現在の登録はIANAにある。現在の対応率、到達率、所有権、Unicode混同事件は示さない。