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

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 を実装する必要があります.