10. ユーザーインターフェースと設定上の問題

アドレスとメッセージヘッダの国際化,特にユニコードに固有の文字コードの変異と組み合わせると,アドレスの慎重な選択とサーバーとDNSレコードの慎重な構成が伝統的なインターネットメールよりもさらに重要になる可能性があります.これらのプロトコルの使用で経験が発達するにつれて,構成とインターフェースのためのガイドラインを提供する1つまたは複数の追加の文書を作成することが望ましいでしょう.MUAと問題,特にダウングレードに関して,議論する文書が開発される予定です.下記のサブセクションは他のいくつかの問題に取り組んでいます.

10.1. メールボックス名と Unicode 正規化の選択

メールの構文は,実際にメールの箱を送信者の幅広い範囲にアクセスできるようにすることを意図している場合,実践的に賢明でないメールボックス名前の選択を許可していることが長い間あった.最も頻繁に引用された例は,ケースセンシビリティの使用とメールボックス内のローカルパーツに埋め込まれた文字の難しい引用を含む.これらの意図的に異常な構造はプロトコルによって許可され,サーバーがサポートされることを期待しています.特殊なケースでは価値を提供することが可能であるが,意図は曖昧さによって何らかのセキュリティを作成しない限り,それらを利用することはほとんど常に悪い慣行です.

これらの拡張機能がないため,SMTP クライアントとサーバーは,RFC 5321によって許可されたアドレスのみを使用することを制限しています.これらのアドレスのローカル部分は,RFC 5321が禁止する制御文字を除く任意の ASCII文字から構成されることがあります.そのうちのいくつかは,そこに指定されているように引用する必要があります.国際化コンテキストでは,いくつかのシステムでは,引用された文字列内の過重 ASCII文字 (文字,バックスペース,および別の文字) を引用された文字列内に使用することが長い歴史があることに注意してください.この形式の国際化はRFC 821 [RFC0821]によって許可されましたが,RFC 5321によって禁止されています.バックスペース文字 (禁止された C0制御) が必要だからです. RFC 5321 (およびその前身RFC 2821) は,ASCIIメールボックス名においてこの文字の使用を禁止し,ASCII以外の文字列ではさらに問題があるため (カノン化および正常化理由のために),バックスペースは SMTPUTF8メールボックス名において出現しない.

ローカル部,ドメイン部,またはその両方に non-ASCII 文字を含むメールボックス名では,Unicode 正規化 [Unicode-UAX15] に特に注意しなければならない (MUST).メールプロトコルとは独立した処理が Unicode 文字列を正規化する場合があるためで,従来のアドレスで引用符の付与・除去時に起こる変換と同様である.したがって,メールボックス名を選ぶ際の指針として次の原則を示す.

• 一般的に,NFKCが目的地メールサーバの担当者が区別がたい文字を一緒にマッピングする状況を除く場合を除き,NFKCに適合するフォームをサポートすると,典型的なユーザーにとってさらに予測可能な行動が得られる.

• 通常,同じローカルパーツ文字列の他の形式を,偽名としてまたは配達サーバに到達する文字列の正常化によってサポートすることが賢明である:送信者が文字列を正常化された形式で送信するには依存すべきではない.

• 異なる形で,より具体的な言葉で述べると,ローカルパーツ文字列のプロトコルの規則は,本質的に次のことを規定する.

  • 標準化されていない文字列は有効だが,世界的に信頼性が低い状態で動作するほど悪い慣行である.サーバーは標準化されたフォームを送信するクライアントに依存すべきではないが,MUAの制御外のクライアントマシンでの手順は,ユーザの意図に関係なく標準化された文字列を送信する可能性があることを認識すべきである.

  • C0 (おそらくC1) 制御 (見 Unicode 標準 [ Unicode ]) は禁止されています.最初ののはRFC 5321で,第二のものは明らかに拡張されたRFC5198で.

  • 他の種類の点検,スペースなどはリスクのある慣行である.おそらく彼らはうまくいくだろうし,SMTP受信コードは深刻なエラーなしで処理するために必要である (そのような文字列がサーバーに配信されるアドレスでは受け入れられない場合でも),しかし,選択されたメールボックス名においてそれらの依存性を生み出すことは通常悪い慣行であり,相互運用性の問題につながる可能性があります.