メインコンテンツまでスキップ

RFC 6530 - 国際化メールの概要と枠組み

  • ステータス: Proposed Standard

  • 公開: 2012年2月

  • ストリーム:IETF

  • 廃止対象: RFC 4952, RFC 5504, RFC 5825

  • エラッタ: エラッタなし

文書情報​

  • RFC番号: 6530

  • タイトル:国際化メールの概要と枠組み

  • 著者:J. Klensin,Y. Ko

  • 日付: 2012年2月

  • カテゴリー: Standards Track

  • 廃止対象: RFC 4952, RFC 5504, RFC 5825

  • ISSN: 2070-1721

概要​

世界中で電子メールを十分に利用するには,他の制約を満たした上で,利用者が自分の言語と文字体系で正しく表記した名前に近い文字列を,メールアドレスのメールボックス名として使える必要がある.本文書は,国際化メールアドレスを完全にサポートするために必要な仕組みとプロトコル拡張を定義する一連の仕様を紹介する.変更には,SMTP 拡張と,UTF-8 データを収容するメールヘッダー構文の拡張が含まれる.また,完全に国際化されたメールを導入する際の主要な前提と問題も論じる.本文書は RFC 4952 を置き換え,同文書の公開後に判明した問題を反映する.

このメモの状態​

本文書は Internet Standards Track 文書である.

本文書は Internet Engineering Task Force (IETF) の成果物であり,IETF コミュニティの合意を表す.公開レビューを受け,Internet Engineering Steering Group (IESG) によって公開が承認されている.インターネット標準については RFC 5741 の 2 節を参照されたい.

本文書の現在の状態,エラッタ,フィードバック方法は http://www.rfc-editor.org/info/rfc6530 を参照されたい.

著作権に関する通知​

著作権 (c) 2012年IETF Trust及び文書の著者として特定された人. すべての権利は保護されています.

本文書には,公開日時点で有効な BCP 78 および IETF Trust Legal Provisions (http://trustee.ietf.org/license-info) が適用される.本文書から抽出した Code Components には,同規定 4.e 節の Simplified BSD License 文を含めなければならず,同ライセンスに記載されたとおり無保証で提供される.

本文書には,2008年11月10日より前に公開または提供された IETF Documents / Contributions の素材が含まれる場合がある.権利者が IETF Trust に,IETF Standards Process 外での改変を許可する権利を与えていない素材については,権利者から十分な許諾を得ない限り,RFC として公開するための整形または英語以外への翻訳を除き,同プロセス外で本文書を改変したり二次的著作物を作成したりできない.

内容表​

1. はじめに​

国際化メールアドレスを利用するには,ドメイン部分とメールアドレスのローカル部分の両方を国際化する必要があります.メールアドレスのドメイン部分はすでに国際化されている [RFC5890],ローカル部分ではない.この文書で指定された拡張なしでは,メールボックス名は7ビット ASCII [RFC5321] のサブセットに限定されています.MIME [RFC2045] はASCII以外のデータの輸送を可能にしますが,国際化メールアドレスのメカニズムを提供していません.RFC 2047 [RFC2047]では,MIME はASCII以外のデータに対応する特定のメッセージヘッダーフィールドのためのエンコーディングメカニズムを定義しています.しかし,ASCII以外の文字を含むメールアドレスの使用は許可されません. ここで定義された拡張子や相当な集合がない場合,電子メールアドレスの一部にASCII以外の文字を組み込む唯一の方法は,RFC 5322 [RFC5322] が"ディスプレイ名" (他の場所では"名前文"として知られている) と呼ぶ内容に RFC 2047 コードを使用して埋め込むこと.ディスプレイ名にコード化された情報はメッセージ封筒に見えません.多くの目的で,アドレスの一部ではありません.

本文書は RFC 4952 [RFC4952] を置き換え,その公開後に判明した追加の問題,共通用語,およびアーキテクチャ上の変更を反映する.RFC 4952 は廃止される.転送中のダウングレードを扱った実験文書 [RFC5504] [RFC5825] も,12 節で説明する変更によって不要になった.RFC Editor には,これら 3 文書を Historic へ移すよう求める.

"彼"と"彼女"は,不確定性の人間を指すのに互換的に用いられる.

この文書の"MUST","MUST NOT","REQUIRED","SHALL","SHALL NOT","SHOULD","SHOULD NOT","RECOMMENDED","MAY"および"OPTIONAL"のキーワードは,BCP 14 のRFC 2119 [RFC2119] で記述されているように解釈する.

2. 本仕様の役割​

本文書は,メール国際化の次の段階に向けたアプローチの概要とフレームワークを提示する.この段階では,アドレスとヘッダーフィールドだけでなく,関連する転送・配信モデルも国際化する必要がある.旧版 RFC 4952 [RFC4952] は一連の実験プロトコル [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] も紹介した.本改訂版は,その一部を継承する Standards Track 仕様の概要と概念を示す.各文書と相互関係は 5 節,実験プロトコルと実装から得た知見は 6 節で説明する.

これらの仕様は国際化メールを実装し支援する方法を定める.本文書は,メール国際化の各要素がどのように組み合わさり,メッセージ転送,ヘッダー形式,処理に関する主要仕様とどう関係するかを説明する.

本文書と関連仕様は,インターネットメールの基本仕様と用語 [RFC5321] [RFC5322],MIME [RFC2045],8BITMIME [RFC6152] を理解していることを前提とする.実装に必須ではないが,IDNA [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] の用語と機能についても一般的な理解を前提とする.

3. 問題提起​

Internationalizing Domain Names in Applications (IDNA) [RFC5890] は国際化ドメイン名を可能にするが,まだ大多数の利用者には普及していない.理由の 1 つは,命名方式全体がまだ国際化されていないことである.ドメイン名は,国際化が必要な多くの名前と識別子の 1 つにすぎず,他の識別子も国際化されるまで,国際化ドメイン名だけでは価値が限られる.

メールアドレスは,ドメイン名を国際化するだけでは十分ではない理由の主要な例である.ほとんどの観察者が経験から学んだように,ユーザーは,意义のない文字列や数字文字列を含むものよりも,名前や初期文字に似ているメールアドレスが大好きである.メールアドレス全体が熟知な文字やフォーマットを使用できない限り,ユーザーはメールを文化的に不友好なものとして認識する.メールアドレスで使用される名前や初期文字がユーザーの母語と文字システムで表現できれば,インターネットは特に母語がローマ系文字のサブセットで書かれていない者によってより自然に認識される.

メールアドレスの国際化は,SMTP envelope や From:, To:, Cc: ヘッダーフィールドを変更したり,MUA が特殊な符号化を復号して現地文字を表示したりするだけでは実現しない.アドレスが現れるすべての文脈で,一貫して国際化し処理する必要がある.個別のパッチや回避策の集合では不十分であり,実装ごとの差異が利用者を混乱させる.必要なのは,同じ言語と文字体系を共有する人々が効率よく通信できる,完全に国際化されたメール環境である.そのためには,適切なヘッダーフィールドで Unicode 全体を使えるようにし,UTF-8 [RFC3629] [RFC5198] のアドレスと拡張ヘッダーフィールドを配送できる SMTP 拡張,配送・サービス通知の国際化 [RFC3461] [RFC3464],および 8BITMIME SMTP 拡張 [RFC6152] のサポートが必要になる.

4. 用語​

この文書は,RFC 5321 [RFC5321]およびRFC 5322 [RFC5322] で文書化されたコアメール標準のプロトコルと用語について合理的な理解を前提とする.

4.1. メールユーザーエージェントとメール転送エージェント​

本文書の多くは Mail Transfer Agent (MTA) と Mail User Agent (MUA) という抽象概念に依存する.ただし,これらの用語と概念は,インターネットメールのアーキテクチャ設計および「protocols on the wire」原則の適用より後に成立した.発展してきたメールアーキテクチャとこの原則のため,同一の送信元・宛先ホストで MTA と MUA がどう相互作用するか,あるいは別の構成要素かについて,強い標準化された区別はない.

しかし,この文書では"最終配信MTA"という用語は,RFC 5321の"配信システム"または"最終配信システム"という用語に相当する形で使用されています.これは SMTPサーバで,アドレスがローカルな部分のフォーマットを制御し,それらを検査し解釈することが許可されています.ネットワークからメッセージが送受信または他のローカル処理のために受信されます.転送を含む,またはリレーではなく封筒アドレスを変更するイラストまたはアライスします.ネットワークの観点から,メッセージストアに保存,特定のメッセージ配信プログラムまたはエージェントへの転送,およびメッセージの回収メカニズムなどのローカル配信の取り決めは,すべて最終的な配信MTAの"後ろ"であり,したがって SMTPまたは配信プロセスの一部ではありません.

4.2. アドレスの文字集合​

この文書では,アドレスが"All-ASCII"または単に"ASCII address"である.アドレス内のすべての文字がASCII文字レパートリー [ASCII] に含まれている場合;アドレスが"non-ASCII"または"i18n address"である. ASCII文字レパートリーに含まれていない場合.そのようなアドレスは他の方法で制限されるが,これらの制限はこの定義に関連していない.この区別が重要である場合,用語"All-ASCII"は他のプロトコル要素に適用され,その反対は"non-ASCII"または"国際化"である.

本文書と関連文書が規定するメールアドレス国際化の総称は SMTPUTF8 である.例えば,本仕様が許可するアドレスを「SMTPUTF8 適合アドレス」と呼ぶ.

ここで示された定義に従って",All-ASCII"アドレスセットと"Non-ASCII"アドレスセットは相互に除外されていることに注意してください. SMTPUTF8 が表示されるときに許可されるすべてのアドレスセットは,これらの2つのセットの結合です.

4.3. ユーザーの種類​

"ASCIIユーザー"は, (i) ASCII文字のみを含む電子メールアドレスを専用使用し, (ii) ASCII文字以外の文字を含む受信者のアドレスを生成することはできません.

「国際化メールユーザー」は,1 つ以上の non-ASCII メールアドレスを持つか,non-ASCII 文字を含む受信者アドレスを生成できる利用者である.ASCII アドレスを併用してもよい.複数のアカウント,対応アドレス,または同一アドレスの複数エイリアスを持つ場合,送信メールで使うアドレスを選ぶ手段を持つ.ASCII アドレスだけを見ても,所有者が国際化メールユーザーかは判断できない.non-ASCII アドレスなら,所有者が国際化メールユーザーであると推測できる.「国際化メールユーザーメッセージ」という概念はなく,この用語は利用者とそのエージェントおよび能力だけに適用する.non-ASCII のメッセージ内容は MIME [RFC2045] の一部であり,本拡張を必要としない.

4.4. メッセージ​

"メッセージ"は,特定の電子メールアドレスを使用して,あるユーザー (送信者) から,受信者の電子メールアドレス (しばしば"ユーザー"または"受信者ユーザー"と呼ばれている) に送信されます.

4.5. メーリングリスト​

「メーリングリスト」は,1 つの受信者アドレスへ送ったメッセージを複数の対象受信者へ配布する仕組みである.その単一アドレスのエージェント (通常は人ではない) が再配布を行い,再配布メッセージの envelope return address (reverse-path) を元の受信者アドレスとは別のアドレスに設定する.これにより,エラーなどの自動生成メッセージはエラー処理用アドレスへ送られる.

ASCII以外のアドレスを含むメールリストを管理するための特別な規定は,そのテーマに特化した文書 [RFC5983]およびその予期される後継者 [RFC5983bis-MailingList] で議論されています.

4.6. 従来型メッセージと国際化メッセージ​

  • 標準メッセージは,SMTP拡張文書 [RFC6531] または UTF8header文書 [RFC6532] で定義された拡張を使用していないもので,この仕様セットで厳密にRFC 5322 [RFC5322] に準拠している.

  • 国際化メッセージは,この仕様セットで定義された拡張機能の1つまたは複数のものを利用したメッセージであり,もはや電子メールメッセージの伝統的な仕様やその輸送に適合していない.

4.7. 配信不能メッセージ、通知、配信確認​

RFC 5321 に規定されているように,何らかの理由で送受信できないメッセージは送信者に通知される.これは2つの方法いずれかで発生する可能性があります.通常"拒否"と呼ばれる SMTP サーバが致命的なエラーを表示する応答コード (5yz"コード) を返還するときに発生します.または一時的な故障エラー (4yz"コード) を持続的に返還します. SMTP 処理中にメッセージを受け入れ,その後送信者にメッセージを生成します.通常は"送受信しない通知"または"NDN"として知られています.現在の慣習は,NDNの生成がスパミング技術として使用される可能性が低下しているため,NDNの生成がNDNに拒否されるのを好む.後者,NDN,次の間接サーバーが拒否するメッセージが受け入れられれば避けられない.

送信者は,これらの国際化拡張について NDN と同じ問題を生じるメッセージ受領通知 [RFC3461] を明示的に要求してもよい (MAY).

5. アプローチと文書構成の概要​

この仕様セットは,SMTPとメールメッセージヘッダの文字コードの両方を変更して,ASCII以外の文字を直接表示できるようにします.作業の各重要な要素は別々の文書で記述されています.そのメンバーが以下のとおり説明されている文書セットには,プロトコルへの実装提案とガイドを提供することを目的とする情報文書も含まれています.

この文書に加えて,次の文書は,この仕様を構成し,助言と文脈を提示します.

  • SMTP拡張子. SMTP拡張文書 [RFC6531] は,国際化アドレスのための SMTP拡張子 (RFC 5321 に規定されているように) を提供します.

  • UTF-8のメールメッセージヘッダ. メールメッセージヘッダ文書 [RFC6532] は,基本的に,UTF-8でコード化されたユニコード文字によって電子メールメッセージヘッダのいくつかの情報を直接表現できるようにRFC 5322を更新します.上記 SMTP拡張子が使用されている場合.この文書は,可能に1つまたは複数の補完型を含む場合,SMTPUTF8と内部 MIMEヘッダとコンテンツタイプ間の関係を含む,MIMEとの相互作用に対処する必要があります.

  • 国際化アドレスに適応するための配達状態と通知処理の拡張 [RFC6533].

  • **今後,IMAPプロトコル (RFC3501) の拡張を指定し,国際化メッセージヘッダ (RFC5738bis-IMAP) をサポートし,POPプロトコル (RFC5721) の並行拡張を指定し,POPIMAP-Downgrade (RFC5721bis-POP3) のいくつかの共通特性も指定する.

6. 実験結果の検討​

このプロトコルセットとそれ以前の実験セットの主要な違いである[RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] は,以前のグループはメッセージのトランジットダウングレードのメカニズムを提供した (RFC5504で詳細に記述されている).そのメカニズムは,ASCII以外の各アドレスがすべてASCIIの相当に付随することを許可し,本質的に要求した.これは,認証できないアドレスペアリングに関連するセキュリティ上の懸念を醸し出した.また,多くの年にわたってインターネットメールアドレスへの最初の互換性のない変更を導入し,新しいアドレスフォームが"リーク"された電子メールの遺産実装に組み込まれれば,相互運用性に関する懸念を醸し出した. これらの仕様の前身の実験的な経験を検証した後,それらを作成した作業グループは,運輸中の格下げの利点が,運用的に可能であれば,これらの懸念を克服するのに十分な重要であると結論付けた.

初期実装の間には相互運用性の問題があったため,そうではないことが判明しました.この仕様セットに至る作業を始める前に,WGは,以前のモデルの要求と長期的な影響の組み合わせが満足できるほど複雑で,作業はそれなしで進めなければならないと結論付けた.

プロトコル自体に対するもう一つの重要な変更は,拡張が必要であれば SMTPUTF8キーワードが SMTPクライアント発表として現在必要である.実験バージョンでは,拡張封筒および/またはコンテンツが許可されているというサーバー発表のみが必要であった.

7. プロトコル拡張と変更の概要​

7.1. 国際化メールアドレス向け SMTP 拡張​

SMTP拡張子"SMTPUTF8"は,次のとおり指定されます.

  • メールアドレス,ローカルパーツとドメイン名の両方で UTF-8 文字列の使用を許可します.

  • メールメッセージヘッダーで UTF-8 文字列を選択的に使用することを許可します (セクション7.2を参照).

  • サーバーが8BITMIME拡張子 [RFC6152] を広告し,クライアントが8ビット送信をサポートすることを要求する.

この作業の基礎となる開発決定には,いくつかの一般原則が影響する.

  1. メールアドレスは,文字集合変換やその他の符号化変更を行う可能性のあるサブシステム (ユーザーインターフェースなど) に渡される.アドレスのローカル部に ASCII 文字レパートリ外の文字が含まれる場合,アドレス全体で一貫した文字処理を促すため,ドメイン部で ASCII 互換エンコーディング (ACE) [RFC3492] [RFC5890] を使用することは推奨されない.

  2. SMTP リレーは,次のいずれかを実行しなければならない (MUST).

    • その形式を明示的に認識し,ESMTP オプションを介して受け入れる.

    • メッセージを拒否するか,必要に応じて配信不能通知を返し,送信者が別の対応を取れるようにする.

  3. 次ホップのシステムがこの拡張を受け入れられないためメッセージを転送できない場合,メッセージを拒否するか,配信不能メッセージを生成して送信しなければならない (MUST).

  4. 相互運用性のため,インターネット上で転送されるメールアドレスおよびメッセージヘッダーでは,UTF-8 以外の文字集合を使用してはならない.大きな複雑さを持ち込まずに,この種の拡張で複数の文字集合を適切に識別する実用的な方法はない.

メール転送および配信に関する標準のグループに適合するには,SMTP拡張仕様と UTF-8ヘッダ仕様を実装する必要があります.システムがIMAPまたは POPを実行する場合,それは国際化 IMAP [RFC5738bis-IMAP]または POP [RFC5721bis-POP3]の仕様に対応する必要があります.

7.2. UTF-8 で符号化されたメールヘッダーフィールドの転送​

MUA や利用者向け表示には,メールアドレスやドメイン名が現れる場所が多い.例として From:, To:, Cc:,通常ドメイン名を含む Message-ID: と In-Reply-To:,およびメッセージ本文がある.それぞれを国際化の観点から検討しなければならない.利用者は,メールボックス名とドメイン名が現地文字で一貫して表示されることを期待する.プロトコル固有の ACE 変種など不透明な符号化を使うと,現地文字ではない形式が時折表示される.メール転送とメッセージ本体で異なる符号化を使う場合も同様である.この問題を中長期的に避ける実用的な方法は,転送で用いる符号化を,メッセージヘッダーや本文で用いる符号化に可能な限り一致させることである.

メールのローカル部を国際化する場合,メッセージヘッダーも完全に国際化された形式にする必要がある.その形式では,ヘッダーフィールドの内容に用いる基本文字集合を ASCII ではなく UTF-8 とする (ヘッダーフィールド名などのプロトコル要素は変更せず,すべて ASCII のままとする).移行と旧来システムとの互換性のため,従来の MIME 符号化モデルを非 ASCII 文字へ拡張する方法も可能だが [RFC2045] [RFC2231] [RFC6532],可能な限り他の符号化方式ではなく UTF-8 に基づくべきである.目標は完全に国際化されたメッセージヘッダーである.

7.3. DSN 向け SMTP サービス拡張​

既存の配達状態通知 (DSN) 仕様 [RFC3461]は,草案規格である.プロトコルの機械読みやすい部分のASCIIテキストに限定されている. "国際配達および配達通知" [RFC6533]は,国際電子メールアドレスのための新しいアドレスタイプを追加し,RFC 3461 [RFC3461] で指定されたORCPTパラメータをサポートする国際化された DSN を実装する必要があります.

8. SMTP トランザクション前後のダウングレード​

重要な問題は,non-ASCII アドレス対応システムと ASCII を前提とする旧来システムの相互作用である.ASCII は国際化形式の適切な部分集合なので,国際化対応システムへ ASCII だけを送ることに問題はない.一方,対応システムが送るメールには,送信者,受信者,または双方の non-ASCII ヘッダー情報が含まれ得る.最初の SMTP サーバーが拡張をサポートしない場合,送信元システムは従来形式の envelope とヘッダーを送る,送信元利用者へ通知する,または [RFC2047] の encoded-word を使って手動で従来形式へダウングレードすることができる.変換には送信者と全受信者の ASCII-only アドレスが必要であり,その発見方法や MUA 等で行う変換は送信システムの設計事項で,本仕様の範囲外である.

初期設定システムがこれらの拡張機能をサポートする際に,より複雑な状況が発生しますが,SMTP送信チェーン内の後のサーバーには対応しません.前向きアドレスによる設定エラーが原因となる場合が多いことに注意してください.特にASCII以外のアドレスがホストされている場合,これらの拡張子を受け入れている最終配信MTAは,以下優先 MXホストで設定されず,送信されない場合.送信される唯一の非ASCIIアドレスがバックポインティングである場合 (例えば,SMTP MAILでは),受信者の設定は一般的に助けられない.一方,送信者向けの代替,すべてASCIIアドレスが送信環境または送信者によって権威的に知られているものである. したがって,これらの拡張を要求する中間 SMTP リレーが,チェーン内の次のシステムがそれらをサポートしていないことを発見した場合,メッセージを拒否または返却する以外に選択肢はほとんどありません.

上記のように,最初のメッセージ送信前にまたは中に ASCIIのみ形式に格下げが起こり得る.メッセージストア,IMAPまたは POPサーバー,または配信MTAとは異なる機能を持つクライアントに対応するために最終配信MTAへの配送後に発生することも可能である.これらのケースは以下のサブセクションで議論されます.

8.1. メッセージ送信前または送信中のダウングレード​

IETFは,従来のMUAの正確な行動を指定して,関連するユーザーインターフェースに最大限の柔軟性を提供することを避けています. SMTP標準 [RFC5321]第6.4節では,MUAと送信サーバーが,結果が公共インターネットに注射された後に"オン・ザ・ワイヤー"基準に適合する限り,ユーザーが提供できるものについて広い範囲を与えています.その伝統では,第8節の残りの部分での議論は,規範的な要求よりも一般的ガイドラインとして提供されています.

これらの拡張機能を必要とするメッセージは,時にはこれらの拡張機能をサポートしないシステムに転送される.最も一般的なケースは,ASCIIのみの前向き指向アドレスとASCII以外の後向き指向アドレスを組み合わせることでしょう.ここで説明されている拡張機能がインターネットメール環境で普遍的に実装されるまで,ヘッダーフィールド内の非ASCIIアドレス (または原始 UTF-8文字) を使用することを好む送信者は,意図された受信者が使用し,すべてのASCIIを使用することを期待する場合でさえ,発生するエラー条件について特に注意する必要があります.送信しないメッセージ (または送信サーバーからの他の指示) が定期的に落とされまたは無視される環境ではリスクは特に大きい.

国際化アドレスに対応する ASCII アドレスを見つけるのに最も便利なタイミングは,MUAまたは密接に関連したシステムにあるかもしれません.これはメッセージが送信される前に,またはメッセージの国際化形式が拒否された後に起こり得る.また,国際化形式から従来の ASCII 形式にメッセージを変換する最も便利な時間であり,または必要に応じて送信者に送送受信しないメッセージを生成する最も便利な時間です.その時点で,ユーザーはバックポインティングアドレスを変更し,代替アドレスのために意図されたバンドから離れた受信者に連絡し,適切なディレクトリを閲覧し,アドレスとメッセージコンテンツの両方を別の言語に翻訳する準備など,さまざまな選択肢があります. メッセージのダグラード化は 完全に自動化されたプロセスだと考えることは当然ですが, 通信を希望する少なくとも中程度の知能を持つユーザの能力を過小評価すべきではありません.

この文脈では,メッセージ送信サーバー (RFC 6409 [RFC 6409] で説明されているように) に変更を加え,ダウングレード操作またはアップグレードを行うように容易に想像できます.このような操作は,ここで議論されている国際化拡張機能の1つまたは複数のメッセージを受け取り,送信サーバーが遭遇する配信または次回の環境に対応するために,必要なように送信メッセージを調整することができます.

8.2. 最終 SMTP 配信後のダウングレードまたはその他の処理​

メールメッセージが最終配信MTAによって受信されると,通常何らかの形で保存されます.その後,保存されたフォームを直接読み取るソフトウェアによってまたは POPや IMAPなどの電子メール取得メカニズムを通じてクライアントソフトウェアによって回収されます.

7.1 節に記載されているSMTP拡張子は,輸送のみで保護を提供します. 保存された国際化アドレスおよび UTF-8 メッセージヘッダを理解するためにアップグレードされていない MUA および電子メール取得メカニズムが,保存された国際化メールにアクセスすることを妨げません.

最終配送MTA (または,より具体的には,対応するメールストレージエージェント) は,電子メールストレージにアクセスするエージェントが常にここで提案された拡張機能に対応できると安全に仮定できないため,国際化されたメールをダウングレード,これらの拡張機能を使用するメッセージまたは両方の特定することが可能である.これらのいずれかまたは両方のアクションが実行される場合,最終配送MTAは,情報損失なしに元の国際化されたフォームを保存または回復するためのメカニズムを含む必要があります. SMTPUTF8認識のエージェントによるアクセスをサポートするために,その情報の保存は必要である.

9. 転送中のダウングレード​

ベースSMTP仕様 (RFC 5321 [RFC5321] 2.3.11節) は",中間ホストが変更することによって輸送を最適化しようとした長い問題史のため,ローカル-パートはアドレスドメイン部分で指定されたホストによってのみ解釈され,セマンティックを割り当てなければならない"と規定している.これは新しい要求ではない.同等の声明は2001年に仕様で出示された [RFC2821] そして1989年にさえ [RFC1123].

この規則の遵守は,電子メールアドレスのローカル部分を変換するダウグレイドメカニズムがトランジットで利用できないことを意味します.それはエンドポイント,特にMUAまたは送信サーバーまたは最終配信MTAによってのみ適用できます.

この規則の理由の一つは,アドレスフィールドのローカル部分にメールルーティング情報を埋め込む古い電子メールシステムに関連しています.電子メールアドレスを変換すると,そのようなルーティング情報を破壊します.最終配信サーバ以外のサーバーは,例えば,ユーザ%のローカル部分が認識できないことを知りません[email protected] 経路 ("ユーザ"は"foo"でアクセスできます) または単にローカルアドレスです.

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受信コードは深刻なエラーなしで処理するために必要である (そのような文字列がサーバーに配信されるアドレスでは受け入れられない場合でも),しかし,選択されたメールボックス名においてそれらの依存性を生み出すことは通常悪い慣行であり,相互運用性の問題につながる可能性があります.

11. その他の問題​

このセクションでは,この仕様セットの一部として,カバーされていない,または包括的にカバーされていない問題を特定しますが,電子メールアドレスおよびヘッダ国際化部署の一環として継続的なレビューを必要とする.

11.1. URI及び IRIへの影響​

メールへの:スケーマ [RFC6068],および国際化資源識別子 (IRI) 仕様 [RFC3987]での議論は,この作業が完了し標準化されると変更されることが必要かもしれません.

11.2. 識別子としてのメールアドレスの使用​

現代インターネット利用では,電子商取引サイトや一部のX.509証明書 [RFC5280] に対応する Web サーバーの識別子として,個人向け識別子として電子メールアドレスが使用される場所がいくつかあります.これらの文書ではこれらの用途に対処していませんが,国際化アドレスが最初にこれらの文脈で使用されると,いくつかの困難が発生すると予想することは合理的です.その多くは,今日許可されているすべてのアドレスを処理することもできません.

11.3. 符号化語,署名済みメッセージ,ダウングレード​

メール形式の特徴の 1 つは永続性である.MUA は数秒前に配信されたものだけでなく,数十年前に送信されたメッセージも処理できることが期待される.したがって,MUA や Sieve [RFC5228] などのメールフィルタリングソフトウェアは,一部のヘッダーフィールドで non-ASCII 文字を表す encoded-word [RFC2047] を引き続き受理し復号する必要がある.POP3 [RFC1939] と IMAP [RFC3501] には,RFC 2047 の復号を含め,符号化された non-ASCII 情報を持つメッセージをサーバー側で自動的にアップグレードする拡張が定義されている.

例えば,S/MIME [RFC5751] や Pretty Good Privacy (PGP) [RFC3156] で暗号学的に署名されたメッセージ部分は,署名を壊さずに RFC 2047 形式から通常の UTF-8 文字へ変換できない.暗号化されたメッセージ部分も,復号後に RFC 2047 符号化のヘッダーフィールドを含む場合があり,暗号鍵へアクセスできなければ完全にはアップグレードできない.

署名済みメッセージを 8.1 節のようにダウングレードし,後で元の形式へ戻して署名を検証する場合も同様である.ダウングレードと再アップグレードで生じるごく小さな変更でも,主要ヘッダーまたは MIME body part header に影響すれば署名を無効にし得る.署名がある場合,ダウングレードは可能な限り避け,行うなら極めて慎重でなければならない.

11.4. ローカル部のその他の用途​

ローカル部はドメインラベルの構築に使われることがある.例えば,[email protected] のローカル部 user をホスト名 user.domain.example に変換し,Web 空間を http://user.domain.example に置き,包括アドレスを [email protected] とする場合である.

これらの制度は,他のものなど,ドメイン名に関するSMTP規則によって制限されていることは明らかであり,他の地域ではさらなる制限なしに機能しない.これらの制限がこれらの仕様に関連しているかどうか,それは開かれた問題である.これは,配送MTAに受け入れられるメールボックス名と解釈の決定において与えられたかなりの柔軟性の別の例である.

11.5. 非標準のカプセル化形式​

いくつかのアプリケーションは,RFC 2046第5.1.5節 [RFC2046] で定義されたメッセージ/消化形式の代わりに,アプリケーション/mbox フォーマット [RFC4155] に似たフォーマットを使用し,複数のメッセージを単一の単位として転送する.そのようなアプリケーションは,すべての保存されたメッセージがRFC 2046第5.2.1節 [RFC2046] で記述されたメッセージ/rfc822 フォーマットを使用すると仮定するので,これらの文書シリーズで指定された拡張機能に準備ができていないため,それらを適切に検出し処理するために特別な措置が必要になる可能性があります.

12. 実験プロトコルおよびフレームワークからの主な変更​

国際化メールアドレスとヘッダーの当初のフレームワークは RFC 4952 と後続の実験プロトコル群で定義された.実験仕様と本仕様群の主なアーキテクチャ上の違いは,前者が転送中のダウングレードをサポートしたことである.その仕組みには,non-ASCII アドレスとともに代替の all-ASCII アドレスを渡す構文と機能,およびダウングレード状態を示す特別なヘッダーが含まれていた.実験により,想定より複雑で必要性が低いと判明したため,これらを削除した.詳細は 6 節と 9 節で説明する.

13. セキュリティに関する考慮事項​

メールアドレスに許可された文字や暗号化フォームの拡張は,いくつかのリスクを伴う.いわゆる"IDN-spoofing"または"IDN homograph attacks"に関する議論が行われた.これらの攻撃は,攻撃者が (または"phisher") が企業または他のエンティティのドメインまたはURLを偽造することを可能にする.同じタイプの攻撃は,国際化されたメールアドレスのローカル部分にも可能である.提案された修正は,すべての表示された要素を標準化された小文字で表示することを含むことを注意すべきです. URLのドメイン名については,URLのローカル部分には対応しません.

メールアドレスがしばしばビスケットカードや紙上のメモから書き換えられているため,混乱した文字から生じる問題にも晒されている (RFC4690参照).メールボックスに関連したドメインが曖昧で,名前が地元のシステム慣習に従う比較的少数のメールボックスをサポートする場合,これらの問題は少し軽減されます.ユーザーは自由に自分のアドレスを選択できる非常に大きなメールシステムにより,それらの名前が増加します.

メールアドレスとメッセージヘッダの国際化により,必要な拡張機能がなければインターネットが安全性が低下させてはならない.この仕様セットに記載されている要件とメカニズムは,一般的に,新しいセキュリティ問題を引き起こすものではない.

混同文字に関連する問題に関するレビューが必要である.他の場所で徹底的に調査されているテーマ (例えば,RFC 4690 [RFC4690]) - そして,RFC 3629 [RFC3629] で議論されている UTF-8 標準化に関する問題や他の変換に関する問題がある. 標準化および変換と標準形式に関連するその他の問題は,他の場所で説明されている作業のテーマの一部である [RFC5198] [RFC5893] [RFC6055].

国際化アドレスとメッセージヘッダに関連するいくつかの問題は,このセットの他の文書でより詳細に議論されています.しかし,特に",ダウングレード"メカニズム,またはダウングレードのアドレスの使用は,国際化およびASCIIアドレス間の認証された結合を不適切に想定しないことを注意する必要があります.この潜在的な問題は,送信ユーザーの管理管理管理下にあるものではなく,送信ユーザーの管理管理下にあると考えられるシステムによって最終配信前にほとんどのまたはすべてのそのような変換が実行されるという期待を強制することによって,少し緩和することができます.

新しい UTF-8 ヘッダーとメッセージフォーマットは,別の既知の問題を引き起こすか悪化させる可能性があります.モデルが"無効"または"不正な"メッセージの新しい形態を作成した場合,新しい電子メール攻撃が作成されます.強固になるため,一部のエージェントまたはほとんどのエージェントはそのようなメッセージを受け入れ,それらを適切にフォーマットしたかのように解釈します.フィルターが受信者が使用するMUAとは異なるメッセージを解釈した場合,フィルターの解釈では受け入れられるように見えるメッセージを作成することが可能になるが,その MUAによって与えられた解釈の下で拒絶されるべきです.そのような攻撃は既存のメッセージやエンコーディングレイヤー,例えば無効なMIME構文,無効なHTMLマークアップ,特定の画像タイプの無効なコーディングなどで既に発生しています.

また,電子メールアドレスはメールを送信以外の多くの文脈で使用されます (例えば,様々な状況下で識別子 (第11.2節を参照). これらの文脈それぞれが評価され,ASCII以外のフォームの使用が適切か,どのような特定の問題を提起するか判断する必要があります.

この作業は,メールヘッダーのデジタル署名などの完全性保護に依存するシステムへ明らかに影響する (11.3 節).PGP と S/MIME の従来の多くの用途は本文部分を署名しヘッダーを署名しないため影響を受けない.一方,DomainKeys Identified Mail (DKIM) [RFC5863] と本仕様は相互に考慮する必要がある.本文書は DKIM などの署名付きヘッダー機構が提起する問題を解決しないが,両者が共存するには調整が必要である.PKI 証明書 [RFC5280] にメールアドレスを含める場合も,国際化アドレスと紛らわしい文字による偽装へ対応するよう関連標準を更新する必要がある.

14. 謝辞​

本文書は,RFC 4952の更新であり,RFC 4952から派生したものである.この文書は,その中で認められた作業や貢献がなければ不可能であっただろう.この文書は,RFC 4952が公表された後,IETF EAI作業グループおよび他の場所での議論,特に国際化メールコレクションにおける他の文書の実験バージョンに関する議論,およびRFC 4952のRFC errataから大幅に利益を得た.

このバージョンの慎重なレビューと提案されたテキストのために,エーニー・デイノウと,慎重なレビューと具体的な提案のために,いくつかのIESGメンバーに特別な感謝があります.

15. 参考文献​

15.1. 規範的参考文献​

  • [ASCII] アメリカ国立標準研究所 (旧アメリカ合衆国標準研究所), "情報交換のための米国コード", ANSI X3.4-1968, 1968.

  • [RFC2119] Bradner, S., "要求レベルを示すためのRFCで使用するキーワード", BCP 14,RFC 2119, 1997年3月.

  • [RFC3629] Yergeau, F., "UTF-8,ISO 10646の変換形式",STD 63,RFC 3629, 2003年11月

  • [RFC5321] クレンシン,J., "シンプルメール転送プロトコル",RFC 5321, 2008年10月.

  • [RFC5322] Resnick, P., Ed., "インターネットメッセージフォーマット", RFC 5322, 2008年10月.

  • [RFC5890] クレンシン,J., "国際化ドメイン名アプリケーション (IDNA):定義と文書フレームワーク",RFC 5890, 2010年8月.

  • [RFC6152] クレンシン,J.,フリード,N.,ローズ,M.,およびD.クロッカー, "8ビットMIME輸送のためのSMTPサービス拡張",STD 71,RFC 6152,2011年3月.

  • [RFC6531] Yao,J.とW. Mao, "国際化メールアドレスのためのSMTP拡張",RFC 6531,2012年2月.

  • **[RFC6532]**ヤング,A.,スティール,S.,およびN.フリード, "国際化メールヘッダ",RFC 6532,2012年2月.

  • [RFC6533] ハンセン,T.,ニューマン,C.,およびA.メルニコフ, "国際化配送状況と配備通知",RFC 6533,2012年2月.

15.2. 参考文献​

  • [POPIMAP-Downgrade] フジワラ,K., "国際化メールメッセージの送迎後のメッセージのDowngrading",Work in Progress, 2011年10月.

  • [RFC0821] Postel, J., "シンプルメール転送プロトコル", STD 10, RFC 821, 1982年8月

  • [RFC1123] Braden, R., "インターネットホストの要件 - アプリケーションとサポート", STD 3, RFC 1123, 1989年10月.

  • [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, 1996年5月.

  • [RFC2045] フリード,N.とN.Borenstein, "マルチパーポースインターネットメール拡張 (MIME) 第1部:インターネットメッセージボディのフォーマット",RFC 2045,1996年11月.

  • [RFC2046] フリード,N.とN.Borenstein, "マルチプルシブルインターネットメール拡張 (MIME) 第2部:メディアタイプ",RFC2046,1996年11月.

  • [RFC2047] Moore, K., "MIME (マルチパーツインターネットメール拡張) 第3部:非ASCIIテキストのためのメッセージヘッダー拡張", RFC 2047, 1996年11月.

  • [RFC2231] フリード,N.とK.ムーア, "MIME パラメーター値とエンコードされたワード拡張: キャラクターセット,言語,および継続",RFC 2231,11 1997.

  • [RFC2821] クレンシン,J., "シンプルメール転送プロトコル",RFC 2821,2001年4月.

  • [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, 2001年8月

  • [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) サービス拡張サービス" (DSNs) RFC 3461, 2003年1月

  • [RFC3464] Moore, K. and G. Vaudreuil, "Delivery Status Notifications の拡張可能なメッセージ形式", RFC 3464,2003年1月.

  • [RFC3492] コステロ,A., "プニコード:アプリケーションにおける国際化ドメイン名 (IDNA) のユニコードのブートストリングエンコーディング" RFC 3492, 2003年3月.

  • [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, 2003年3月

  • [RFC3987] デュエルスト,M.およびM.スイナード, "国際化資源識別子 (IRI)",RFC 3987,2005年1月.

  • [RFC4155] Hall, E., "アプリケーション/mbox メディアタイプ", RFC 4155, 2005年9月.

  • [RFC4690] クレンシン,J.,ファルトストロム,P.,カープ,C.,およびIAB, "国際化ドメイン名 (IDN) のレビューと勧告"RFC 4690,2006年9月.

  • [RFC4952] クレンシン,J.とY.コ, "国際化メールの概要と枠組み",RFC 4952,2007年7月.

  • [RFC5198] クレンシン,J.とM.パドリプスキー, "ネットワーク交換のためのユニコードフォーマット",RFC5198,2008年3月.

  • [RFC5228] グエンサー,P.とT.ショワルト, "Sieve: An Email Filtering Language",RFC5228,2008年1月.

  • [RFC5280] クーパー,D.,サンテッソン,S.,ファレル,S.,ボイエン,S.,ハウスリー,R.,およびW.ポーク, "インターネットX.509公共鍵インフラ証明書および証明書撤回リスト (CRL) プロファイル",RFC 5280,2008年5月.

  • [RFC5335] Yang, A., "国際化メールヘッダ", RFC 5335, 2008年9月.

  • [RFC5336] Yao,J.とW. Mao, "国際化メールアドレスのためのSMTP拡張",RFC 5336,2008年9月.

  • [RFC5337] Newman, C. and A. Melnikov, "国際化配達状況と配備通知", RFC 5337, 2008年9月.

  • [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, 2009年3月.

  • [RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8", RFC 5721, 2010年2月.

  • [RFC5721bis-POP3] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "POP3 Support for UTF-8", Work in Progress, 2011年11月

  • [RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 5738, 2010年3月.

  • [RFC5738bis-IMAP] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Support for UTF-8", Work in Progress, 2011年12月.

  • **[RFC5751]**Ramsdell,B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification",RFC 5751, 2010年1月.

  • [RFC5825] Fujiwara, K. and B. Leiba, "Displaying Downgraded Messages for Email Address Internationalization", RFC 5825, 2010年4月.

  • [RFC5863] ハンセン,T.,シゲル,E.,ハラム-ベーカー,P.,およびD.クロッカー, "ドメインキー識別メール (DKIM) 開発,展開,および運用",RFC 5863,5月 2010.

  • [RFC5891] クレンシン,J., "国際化ドメイン名アプリケーション (IDNA):プロトコル",RFC 5891, 2010年8月.

  • [RFC5892] Faltstrom, P., "Unicode Code Points and Internationalized Domain Names for Applications (IDNA) " (アプリケーションのためのユニコードコードポイントと国際化ドメイン名) " (RFC 5892) 2010年8月.

  • [RFC5893] アルヴェストランド,H.とC.カープ, "国際化ドメイン名 (IDNA) の右から左のスクリプト" RFC 5893, 2010年8月.

  • [RFC5894] クレンシン,J., "国際化ドメイン名 (IDNA):背景,説明,合理化",RFC 5894, 2010年8月.

  • [RFC5983] Gellens, R., "Mailing Lists and Internationalized Email Addresses", RFC 5983, 2010年10月.

  • [RFC5983bis-MailingList] レヴィン,J.とR.ゲレンズ, "メールリストとUTF-8アドレス",Work in Progress, 2011年12月.

  • [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IABの国際化ドメイン名へのエンコーディングに関する考え", RFC 6055, 2011年2月.

  • [RFC6068] Duerst, M., Masinter, L., J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, 2010年10月.

  • [RFC6409] Gellens, R. and J. Klensin, "メールへのメッセージ送信", STD 72, RFC 6409, 2011年11月.

  • [Unicode] Unicode Consortium, The Unicode Standard, Version 6.0.0, 2011, ISBN 978-1-936213-01-6. http://www.unicode.org/versions/Unicode6.0.0/

  • [Unicode-UAX15] Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", 2010年9月. http://www.unicode.org/reports/tr15/