インターネットのメールは、送ってから相手に届くまでに沢山のマシンを経由します。今日と明日では、別のマシンを経由するかもしれません。
だから、どんなマシンでも通用する形式にする必要があるのです。
インターネットのメールシステムは米国で育ったため、英語用であるASCIIを対象に作られました。ASCIIの文字は7ビットで表現出来るため、初期の頃は7ビット分だけを通すネットワークがあり、インターネットメールもこれに合わせた仕様に決められました。
現在のインターネットはほぼ間違いなく8ビットが通りますが、メールの転送では基本的に7ビットだけを通す事になっています。
とりあえず、ASCIIだけのメールを見てみましょう。
この形式を
等と呼びます。便箋の事だと思ってください。
この便箋は、ヘッダ (header)と本文 (body)の2つから成り立ちます。
便箋の上の方に「××より、○○さんへ」といった連絡事項を書くのがヘッダであり、その後に1行あけてから本文が続くわけです。
ただし、メールソフトによってはヘッダと本文は別々に表示されるかもしれません。
一番下に署名(signature)を付ける事がありますが、これは本文の一部です。署名の区切りとして「-- 」(ハイフン ハイフン スペース)を使う事がありますが、これは単なる習慣です。そういう決まりがあるわけではありません。一部のネットニュースのシステムで使われていたのが由来です。
本文は人間が読んだりする為のものですが、ヘッダは機械が処理に使ったりします。だから別々に考えましょう。
もし、8ビットのメールを出してしまうと、昔ながらの7ビットのメールしか通さない機械やソフトを経由した途端、1ビット分が失われます。つまり文字化けです。これを避けるため本文では7ビットのJISを使う方法が考え出されました。こいつは後になってISO-2022-JPという名前が付きました。
逆に言えば、ISO-2022-JPに含まれない文字は使えないのです。
一方、EUC-JPやShift_JISはインターネットで使う事は考えられていなかったので、8ビットを組み合わせたコードになっており、十分な配慮がなければちゃんと届く保証はありません。一部のコンピュータの内部で使う事を前提に作られたものですから、対応していないソフトが多数あり、相手側で読めるかどうかもわかりません。
ヘッダに日本語を使うと、マシンやソフトが処理を失敗することがあるのでASCIIで書かなければいけません。
これでは不便なので、MIMEの"B" encodingや"Q" encodingやRFC2231という方法が考え出され、日本語を使うことが出来るようになりました。しかし、これに対応してないソフトもあります。詳しくは[8.3]で説明します。
上で示したような無難な形式で送受信する為にはメールソフト等の設定をしなければならない場合があります。それぞれのマニュアルを見て下さい。
正しく動作するメールソフトは、次のように文字コードと行の区切りを変換する筈なので、読み書きするときに気にする必要はないでしょう。
DOSのメールソフトの場合 DOS側 インターネット側 本文 Shift_JIS ←変換→ ISO-2022-JP (JIS) ヘッダ Shift_JIS ←変換→ ISO-2022-JPの"B" encoding 行の区切り CR LF← → CR LF
Linuxのメールソフトの場合 Linux側 インターネット側 本文 EUC-JP ←変換→ ISO-2022-JP (JIS) ヘッダ EUC-JP ←変換→ ISO-2022-JPの"B" encoding 行の区切り LF←変換→ CR LF
どういう訳か、ISO-2022-JP (JIS)以外の文字コードが初期設定になっているソフトが実在しますが、無難とは言えません。独自方式を想定していると言っているメーカもあります。インターネット用なのに独自とは本末転倒ですが…
また、Shift_JISしか扱えないソフトも希にありますが、数人の作者に直接問い合わせたところ、十分な知識がないのが原因でした。十分な知識を持った人が「Shift_JISでなければならない」と主張しているケースには出会っていません。
一方、行の区切りの設定はほとんど見かけません。最初からCR LFに変換するようになっていると思われます。間違っているソフトはありますが、かなり少数です。
メールソフトではちゃんと読めるのに、メールを保存したファイルをテキストエディタ等で表示すると化けて見えることがあります。
これは変換前のファイルを見てるか、そのメールソフト独自の形式を見てるか、どっちかでしょう。[11] 文字化けすると、こう見える！参照
インターネットメッセージフォーマットは、もともとARPAというネットワークで使われていた幾つかのメール標準をまとめあげ、更に多くの人の意見を取り入れたRFC822という文書にさかのぼります。これはRFC1123で部分的に修正され、長い間使われてきました。
現在は、2001年4月に発行されたRFC2822に置き代わっています。
RFC2822で決められたインターネットメッセージフォーマットは、ASCIIのテキストだけを扱います。
ASCII以外の文字コードやバイナリ(音声、画像、動画等)を扱う場合は、MIMEという拡張方法を使う事になっています。
MIMEはRFC2045, 2046, 2047, 2048, 2049等に記載されています。Multipurpose Internet Mail Extensionsの略です。
MIMEでは8ビットのデータを7ビットのASCIIに変換する方法が色々あります。
場合によってこれらが使い分けられます。
RFC2047の4. Encodingsの項には、ヘッダのほとんどの文字がASCIIの場合は"Q" encodingを推奨する(recommended)と書かれています。この理屈で、latin1のヘッダは"Q"になっている事が多いです。
RFC1468のMIME Considerationsの項には、ISO-2022-JPのヘッダは"B"の方を使うべきだ(should be)と書かれています。
MIMEの決まりに従ってファイルを添付した場合、ファイル名はヘッダのパラメータに書かれます。かつてこの部分はASCIIしか認められていませんでしたが、RFC2231の登場によって日本語ファイル名も使えるようになりました。しかしながら、実際にはこの規則を破ってISO-2022-JPのままや"B" encodingを使っているケースが多いです。
本文がlatin1の場合、quoted-printableを使う事が多いです。本文にバイナリを添付する場合はbase64が多いです。本文に日本語を使う場合は、ISO-2022-JPをそのまま使います。ISO-2022-JPは最初から7bitですから、それ以上変換する必要がありません。
インターネットでメールを転送するためには、SMTP (Simple Mail Transfer Protocol)という方法を使います。
元々、これは7ビットのネットワークも考慮しているし、ASCIIが前提です。だから7ビット分だけ扱います。
8ビットも扱えるネットワークでは、一番上のビットを特別な用途で使用している場合もありました。そこで、「一番上のビットをゼロにする」という方法で互換性を保ちます。
SMTPで接続したとき、送信側は受信側に「HELO 云々」という文字列を送る決まりがあります。
後になって、SMTPを拡張する方法が登場しました。これを特にESMTPと呼ぶ場合があります。SMTP Service Extensions または Extended SMTP の略です。
この場合、「HELO 云々」の代わりに、「EHLO 云々」という文字列を送ります。受信側がEHLOにエラーを返したら、古いSMTPにしか対応していない事がわかります。対応してる場合は、受信側はどんな拡張が使えるかを教えてきます。
SMTPとESMTPをまとめて、単にSMTPと呼ぶ場合も多いです。
現在はHELOとEHLOの両方をサポートしなければなりませんが、なるべく新しい方のEHLOを使うべきだとされます。実際には古い方のHELOも結構使われてます。
SMTPはRFC821に記載され、RFC974, 1123と併せて読む必要がありました。
ESMTPによる拡張方法はRFC1869に記載されていました。
沢山読む必要があったわけですが、現在は2001年4月に発行された一つの文書RFC2821に置き代わっています。
様々な拡張機能は別々に定義されており、例えば次の様なものがあります。
昔ながらのSMTPの場合、8ビットのデータが来たときは、一番上のビットをゼロにしなければなりません。このルールは昔から今に至るまで、変わっていません。
現在のESMTPの場合、まず送信側が「EHLO」を送り、次に受信側が「私は8ビットの拡張に対応してます」と宣言し、更にそれを送信側が確認してから「これから8ビットデータを渡します」と宣言したときのみ、8ビットが通ります。この取り交わしが行なわれない場合、一番上のビットをゼロにしなければなりません。
しかし実際には、何の取り交わしも行なっていないのに8ビットを通すサーバが沢山あります。この場合、壊れずに届く事自体が間違いです。
このあたりのルールは、RFC1652, 2821, 3030に載っています。
また、SMTPではない独自仕様でメールを渡す場合は、どうなるかわかりません。共通の決まりがないのですから。
かなり古い転送方法です。最近はほんの一部のネットワークでしか使われていないでしょう。
もともとはUNIX-UNIX間でファイルをコピーする方法です(Unix to Unix CoPy)。
メールの配送に使う場合、一度メールを溜めておいて、しばらくしてからまとめて次に渡します。回線が今ほど充実していなかった時代、一気に全部送ってすぐ回線を切れば料金が安くすむという利点があったわけです。ただし、相手に届くまでに時間がかかるという欠点もあります。
RFC976, 1137に情報があります。
SMTPはメールが届くのを24時間ずーっと待っています。常に動きっぱなしのマシンなら問題ないですが、毎日電源を切るようなパソコン等には不向きです。
そういうマシンではPOP (Post Office Protocol)という方法で、サーバに届いたメールを受け取りに行きます。私書箱の概念ですね。
メールソフトによっては、「 POPサーバにメールを残す」という設定がありますが、溜まりすぎると消されちゃうかもしれません。サーバの設定が悪いとパンクして停止するかもしれません。
最近はバージョン3 (POP3)が主流で、これはRFC1939に記載されています。8ビットもokです。
RPOPというのはPOP3のオプション機能で、信頼出来るコンピュータの信頼出来るユーザからのアクセスはパスワードをいらなくする仕組みでしたが、既に廃止されています。
APOPというのはPOP3のオプション機能で、第三者にパスワードを盗まれにくくする仕組みです。
KPOPというのはRFCには出てこない言葉ですが、これはKerberosという認証を行なってPOPでアクセスを行なうものの事でしょう。KerberosはRFC1510等に載っています。
POPはメールを「取りに行く」方法ですが、IMAPは「読みに行く」方法です。IMAPサーバ側に保管しておくので、POPサーバよりも余裕が必要です。
最新はバージョン4リビジョン1 (IMAP4rev1)で、これはRFC3501に記載されています。
なお、IMAPはInternet Message Access Protocolの略ですが、Internet Message Action Protocolとしている文書(RFC3348)もあります。
メールはヘッダと本文の2つで構成され、便箋なのだと説明しました。これとは別に封筒(エンベロープ)もあります。 このエンベロープはメールソフトやサーバが自動的に生成していますから、ユーザが普通にメールを読み書きしていても目に触れないかもしれません。
例えば、SMTPの一般的なエンベロープには、MAIL FROM:とRCPT TO:という行があります。
MAIL FROM:は封筒に書かれた送信者のアドレスです。もし配送に問題が出た場合、このアドレス宛に通知メールが届く筈です。
RCPT TO:は封筒に書かれた受信者のアドレスです。
配達人(メールサーバ)は、便箋(メールヘッダと本文)を読むのではなく、封筒(エンベロープ)のアドレスを読んで配送を行なっています。
だから、受け取ったメールのTo:やCc:に自分のアドレスが書かれていない事が実際にあります。
また、ヘッダのFrom:とSMTPエンベロープのMAIL FROM:が異なる場合もあります。エラー通知はオリジナルの著者ではなく管理者に届いた方が都合がいい場合等です。
RFC2822自身にenvelope and contents
という表現があります。
なお、「封筒と便箋」ではなく、「ハガキの表と裏」に喩えているケースもありますが、これはメールの内容が他人の目に触れやすい事を説明したい場合でしょう。
X.400とは、CCITT (現ITU-T)というところが作り、国際標準規格ISOになっている電子メールシステムの事です。インターネットメールとは別のものですから、ここでは説明していません。X.400とインターネットメール間で交換する方法については、RFC2156, 2157等に書かれています。
なお、MHS、MTA、UAという言葉は、このX.400の用語がインターネットメールでも使われるようになったものです。
携帯電話、パソコン通信、グループウェア、一部のプロバイダ等の電子メールでは、ここで紹介したものとは異なる独自形式を使っているかもしれません。インターネットとの間を繋ぐ機械が、インターネット形式との変換をしている筈です。それぞれの管理者に問い合わせてください。
送信側と受信側の両方が、日本語(ISO-2022-JP)に対応しなければなりません。日本語対応と書かれていない場合でも可能かもしれませんが、十分な知識が必要になるでしょう。
途中で経由するサーバにはSMTP、POP、IMAP等がありますが、これらは「日本語対応」と書かれてなくても大丈夫な筈です。そういうサーバでも問題ないように考えられたのがISO-2022-JPなのですから、あたりまえです。
日本国外のパソコン通信、グループウェア、一部のプロバイダ等が、SMTPじゃない独自形式だと面倒かもしれません。独自形式はISO-2022-JPの事まで考えてないかもしれないのです。もしそれが未対応だったら、正常な日本語メールを読み書き出来る可能性は低いでしょう。
これらの条件が整わない場合は、[12.6.2]を参考にしてください。