この RFC はインターネット・コミュニティーのために情報を提供するものであり、インターネット標準を定めるものではない。 このメモの配布に制限はない。
SMTP を拡張して 8 ビット文字を通してしまおうというプロトコルが定義された [3] [4]。 これらのプロトコルでは、拡張 SMTP によって搬送されるメッセージは MIME [1] [2] で符号化されていることが求められる。 これらのプロトコルが開発に着手される以前は、SMTP のいくつかの実装が 8 ビットのデータを送るために場当たり的なメカニズムを採用していた。 それらの場当たり的メカニズムと拡張 SMTP 環境とは相互運用できることが望ましい。 この文書では、そうした環境における諸問題と、現在の非 MIME の 8 ビット・メッセージの利用から MIME への移行のコストを最小限に抑えるためのアプローチとについて概説する。
RFC 821 は 7 ビットの搬送を定義している。 SMTP メッセージ中の最上位ビットの立っているオクテットを受け取った際にそのビットをクリアしない搬送エージェントを、この文書では 8 ビット透過と呼ぶ。 汎用の SMTP 拡張文書 [3] およびオクテットの全 8 ビットを使って MIME メッセージを伝達する 8 ビット拡張プロトコル [4] の実装は、8 ビット ESMTP と呼ばれる。 8 ビット文字を受け付けない拡張 SMTP の実装は、7 ビット ESMTP と呼ばれる。 ゲートウェイは、ユーザー・エージェントの権限をもち、メッセージの内容を変更ないし変換する搬送エージェントとして定義される。
RFC 821 で定義されているように、SMTP はインターネット・メールの送信を US-ASCII 文字 [5] に限定している。 インターネットが非英語圏の通信者を擁して拡大するにつれ、US-ASCII 以外の文字集合で通信する必要から多くのベンダーや利用者は SMTP や RFC 822 を拡張して非 ASCII 文字集合が使えるようにしてきた。 そのアプローチとして、現在の RFC822/SMTP によって 7 ビットの ISO 646 文字集合の各国版を送るアプローチ、8 ビットの ISO 8859 文字集合が使えるように SMTP および RFC822 を拡張するアプローチ、独自の PC 文字集合を用いるアプローチが一般的である。
さらに別のアプローチが日本語メールで使われている。 日本語文字は最上位ビットのクリアされた一対のオクテットで表現される。 14 ビットの文字集合と 7 ビットの文字集合との切り替えは、メッセージ中の ISO 2022 のエスケープ・シーケンスによって指示される。
これらの実装は、中間での変形なしに通信することができ、かつタグづけせずに特定の文字集合を使用することに関して緩やかな私的合意がある限り、基本的なメール・サービスが提供できる。
折衝を要する 8 ビット ESMTP/MIME 環境への移行においては、現時点で対応していない利用者によって送信されたメールが別の非対応の利用者にも読めることが重要である。 現在は機能しているこの状態が、8 ビットのテキストから Base-64 で符号化された判読不能なテキストや quoted-printable で符号化された “文字化け” のテキストへ変換することによって損なわれてしまう。
非 US-ASCII メールには、相互運用不能となる興味深い状況がいくつか現存する。 また、8 ビット MIME への移行に際して浮上しそうな問題もいくつか存在する。 下図は、MIME へ移行する場合を列挙したものである。 このメモでは、変換をおこなうゲートウェイとの関連で (4) に対する解決策についてのみ議論する。
| 受 信 側 | ||||
|---|---|---|---|---|
| 7 ビットのみ | 8 ビット透過 | MIME/ESMTP | ||
| 送 信 側 |
7 ビットのみ | (1) | (1) | (1) |
| 8 ビット透過 | (2) | (3) | (4) | |
| MIME/ESMTP | (5) | (5) | (6) | |
(1) 送信側が 7 ビット非 MIME で、受信側が 7 ビット、MIME、または 8 ビット透過である場合
この場合は、送信側と受信側の間に外的な “帯域外” の合意があれば、ISO 646 ないし ISO 2022 文字集合の各国語版へ移行することで変わらず機能し続けるはずである。 7 ビットから 8 ビット ESMTP へ変換するゲートウェイがこのメッセージの内容を変更する必要はない。
(2) 送信側が 8 ビットで、受信側が 7 ビット非 MIME である場合
受信側はビットの落とされたメールを受け取ることになる。 その結果、データは誤って解釈され、間違った文字が表示されたり印字されたりする。 ほとんどの文字が ISO 8859 の US-ASCII 部分集合に属する言語を使って送られたメールであれば、多少は読めるかもしれない。
(3) 送信側が 8 ビット透過で、受信側も 8 ビット透過である場合
送信側と受信側の間に特定の文字集合をタグづけなしに用いることについて外的な “帯域外” の合意があれば、機能する。
(4) 送信側が 8 ビット透過で、受信側が MIME/ESMTP 準拠である場合
適当なアップグレード・パスがゲートウェイを介して提供され、正しく指示された文字集合タグがゲートウェイによって挿入され、かつ送信側によって選択された文字集合を受信側がサポートするならば、機能する。 このケースがこのメモの焦点である。
(5) 送信側が MIME/ESMTP で、受信側が非 MIME 7 ビットである場合
ESMTP/MIME の送信側は受信側が 8 ビットを理解するか否か知り得ないため、送信側はテキストを Base-64 または quoted-printable に符号化することになるが、受信側はそれを “文字化け” していると見做すかもしれない。 有用なダウングレード・パスを提供するには、ゲートウェイには受信側の能力について何らかの知識がなければならない。 文字集合が明確に識別できる場合には、RFC 1345 に記述されている MNEM 符号化法のようなテクニックが役立つかもしれない。
(6) 送信側が MIME/ESMTP で、受信側も MIME/ESMTP である場合
送信側によって選択された文字集合を受信側がサポートするならば、相互運用性は達成される。
拡張 SMTP をサポートするようにアップグレードされたゲートウェイは、受け取った 8 ビットのメッセージを MIME にアップグレードしてもよい。 これは、ESMTP によって送られる 8 ビットのメールはすべて MIME に符号化されなければならないという要件に合致する。 アップグレードは、利用できる最善の情報を用いてなされるべきである。
サイトは、そのサイトを離れるすべてのメッセージの MIME 変換を実装することによって総 MIME に “アップグレード” してもよい。 テキスト・メッセージの場合、その本文は、MIME-Version ヘッダーとそのサイトで用いられている文字集合を示した Content-Type: Text/Plain とを付け加えることで変換できる。 ただし、そのサイトが単一の文字集合を使用している場合に限る。
必要な符号化法を示す適切な Content-Transfer-Encoding ヘッダーの行も追加しなければならない。
例を示す。
MIME-Version: 1.0 Content-Type: Text/Plain; Charset = ISO-8859-1 Content-Transfer-Encoding: 8bit
用いられている文字集合についての情報が入手できない場合、ゲートウェイは文字集合 "unknown-8bit" を使ってメール内容をアップグレードすべきである。 charset パラメーターにおける unknown-8bit の値は、単にメッセージに用いられている文字集合についての信頼できる情報が得られなかったことを示すものである。
メッセージ本文が MIME にアップグレードされた場合、非 US-ASCII 文字を含む RFC 822 ヘッダーも RFC1342 のヘッダー符号化規則に準拠するようにアップグレードしなければならない。 ゲートウェイは、構造化されていないすべてのヘッダー・フィールドを、RFC 822 の comment や phrase と同様、RFC 1342 の規則に従って符号化し直すべきである。 RFC 1342 には、メッセージ本文のための "8bit" という Content-Transfer-Encoding の値に相当するものがないため、8 ビットのヘッダー・テキストはすべて "B" か "Q" のいずれかの符号化方法によって変換しなければならない。 ISO 8859 文字集合の場合は、一般に "Q" 符号化法のほうがある程度まで読解可能なヘッダーになる。
トレース情報は、次に例示するように、"rfc822-to-8bit"、"rfc822-to-base-64"、または "rfc822-to-quoted-printable" の convert 句を付けて追加すべきである。
Received: from dbc.mtview.ca.us by dbc.mtview.ca.us
convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700
ここでは、MIME の Content-Type フィールドで使用する charset パラメーターの値をひとつ定義する。
"unknown-8bit" という特殊用途の文字集合は、オクテット列に符号化された未知の 8 ビット文字集合として定義される。 これは、いかなる言語のいかなる符号化法を使ったいかなる文字集合にもラベルとして用いることができる。 これ以上の定義はしてはならない。
"charset=" フィールドにおけるこのトークンの使用は、用いられている文字集合について何ら既知の情報がないことを示す。 この標識は、非 MIME から MIME へのゲートウェイによって使用されることが意図されている。 具体的には、SMTP から 8 ビット ESMTP/MIME へ変換するゲートウェイである。
この文字集合は、メール作成ソフトによって用いられることは意図されていない。 メール作成ソフトには使用されている文字集合が分かっており、[1] で定められているとおりにそれを文字集合の値で標識づけるものと想定される。 文字集合を示す値は最新の「割り当て番号」文書 [6] により改定されている。
unknown-8bit ラベルは、意図された文字集合を帯域外情報によって確定することのできないメール・ゲートウェイ・エージェントだけが使用できるものである。
unknown-8bit の解釈は、メール・リーダー・ソフト次第である。 多くの場合、人間がその情報を解釈し、適切な文字集合ないし前処理ソフトを選ぶことができるものと想定される。
この文書は、Ned Freed、Neil Katin の両氏および筆者による廊下での立ち話に端を発する。 Jonathan Laventhol、Craig Everhart、Olle Jarnefors、Olafur Gudmundsson の各氏からは多大なる助言を受けた。 IETF の SMTP 拡張作業部会の多くの参加者からの意見によって文書を洗練した。
| [1] | Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1341, Bellcore, Innosoft, June 1992. |
| [2] | Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1342, University of Tennessee, June 1992. |
| [3] | Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", RFC 1425, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993. |
| [4] | Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions for 8bit MIMEtransport", RFC 1426, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993. |
| [5] | Coded Character Set--7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. |
| [6] | Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. |
セキュリティーの問題はこのメモでは議論しない。
Greg Vaudreuil
Corporation for National Research Initiatives
1895 Preston White Drive, Suite 100
Reston, VA 22091 USA
Phone: (703) 620-8990
EMail: GVaudre@CNRI.Reston.VA.US