インターネットのメールは、送ってから相手に届くまでに沢山のマシンを経由します。今日と明日では、別のマシンを経由するかもしれません。
だから、どんなマシンでも通用する形式にする必要があるのです。
インターネットのメールシステムは米国で育ったため、英語用であるASCIIを対象に作られました。ASCIIの文字は7ビットで表現出来るため、初期の頃は7ビット分だけを通すネットワークがあり、インターネットメールもこれに合わせた仕様に決められました。
この仕様は現在も同じであり、英語以外のメールは苦労が絶えません。
とりあえず、ASCIIだけのメールを見てみましょう。
この形式を
等と呼びます。便箋の事だと思ってください。
この便箋は、ヘッダ (header)と本文 (body)の2つから成り立ちます。
便箋の上の方に「××より、○○さんへ」といった連絡事項を書くのがヘッダであり、その後に1行あけてから本文が続くわけです。
ただし、マシンやメールソフトによってはヘッダと本文は別々に表示されるかもしれません。
本文は人間が読んだりする為のものですが、ヘッダはマシンが処理に使ったりします。だから別々に考えましょう。
もし、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 <--> MIME "B" encoding 行の区切り CR LF <--> CR LF Linuxのメールソフトの場合 Linux側 インターネット側 本文 EUC-JP <--> ISO-2022-JP (JIS) ヘッダ EUC-JP <--> MIME "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ビットも扱える場合は「一番上のビットをゼロにする」という方法で互換性を保ちます。
現在のほとんどのネットワークは8ビットが扱えるようになっており、8ビットを無条件に通してしまうSMTPサーバも沢山ありますが、本当は間違いです。
後になって、SMTPを拡張する方法が登場しました。これをESMTPと呼びます。 SMTP Service Extensions または Extended SMTP の略です。最近は、この拡張機能が使えるサーバが増えています。送り側は接続したときにESMTP対応かどうか、どの拡張が使えるかを確認してからメールを渡すという手順を取ります。
SMTPはRFC821に記載され、RFC974, 1123と併せて読む必要がありました。
ESMTPによる拡張方法はRFC1869に記載されていました。
沢山読む必要があったわけですが、現在は2001年4月に発行された一つの文書RFC2821に置き代わっています。
様々な拡張機能は別々に定義されており、例えば次の様なものがあります。
かなり古い転送方法です。最近はほんの一部のネットワークでしかサポートされていません。
もともとはUNIX - UNIX間でファイルをコピーする方法です(Unix to Unix CoPy)。
メールの配送に使う場合、一度メールを溜めておいて、しばらくしてからまとめて次に渡します。だから相手に届くまでに時間がかかります。
電話回線等の場合、一気に全部送ってすぐ回線を切れば、料金が安くすむという利点があります。
RFC976, 1137に情報があります。
SMTPやESMTPはメールが届くのを24時間ずーっと待っています。常に動きっぱなしのマシンなら問題ないですが、毎日電源を切るようなパソコン等には不向きです。
そういうマシンではPOP (Post Office Protocol)という方法で、サーバに届いたメールを受け取りに行きます。私書箱の概念ですね。
メールソフトによっては、「 POPサーバにメールを残す」という設定がありますが、溜まりすぎると消されちゃうかもしれません。サーバの設定が悪いとパンクして停止するかもしれません。
最近はバージョン3 (POP3)が主流で、これはRFC1939に記載されています。8ビットもokです。
RPOPというのはPOP3のオプション機能で、信頼出来るコンピュータの信頼出来るユーザからのアクセスはパスワードをいらなくする仕組みでしたが、既に廃止されています。
APOPというのはPOP3のオプション機能で、第三者にパスワードを盗まれにくくする仕組みです。
KPOPというのはRFCには出てこない言葉ですが、これはKerberosという認証を行なってPOPでアクセスを行なうものの事でしょう。KerberosはRFC1510等に載っています。
POPはメールを「取りに行く」方法ですが、IMAP (Internet Message Access Protocol)は「読みに行く」方法です。IMAPサーバ側に保管しておくので、POPサーバよりも余裕が必要です。
最新はバージョン4リビジョン1 (IMAP4rev1)で、これはRFC2060に記載されています。
メールはヘッダと本文の2つで構成され、便箋なのだと説明しました。これとは別に封筒(エンベロープ)もあります。 このエンベロープはメールソフトやサーバが自動的に生成していますから、ユーザが普通にメールを読み書きしていても目に触れないかもしれません。
例えば、SMTPやESMTPの一般的なエンベロープには、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、ESMTP、POP、IMAP等がありますが、これらは「日本語対応」と書かれてなくても大丈夫な筈です。そういうサーバでも問題ないように考えられたのがISO-2022-JPなのですから、あたりまえです。
日本国外のパソコン通信、イントラネット、一部のプロバイダ等が、SMTPやESMTPじゃない独自形式だと面倒かもしれません。独自形式はISO-2022-JPの事まで考えてないかもしれないのです。もしそれが未対応だったら、正常な日本語メールを読み書き出来る可能性は低いでしょう。
これらの条件が整わない場合は、[12.6.2]を参考にしてください。