インターネットのメールは、送ってから相手に届くまでに沢山のマシンを経由します。今日と明日では、別のマシンを経由するかもしれません。
だから、どんなマシンでも通用する形式にする必要があるのです。
インターネットのメールシステムは米国で育ったため、英語用である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] メールヘッダで説明します。
上で示したような無難な形式で送受信する為にはメールソフト等の設定をしなければならない場合があります。それぞれのマニュアルを見て下さい。
設定を行なったメールソフトは、次のように文字コードと行の区切りを変換する筈なので、読み書きするときに気にする必要はないでしょう。
MacOSのメールソフトの場合 MacOS側 インターネット側 本文 Shift_JIS <--> ISO-2022-JP (JIS) ヘッダ Shift_JIS <--> MIME "B" encoding 行の区切り CR <--> CR LF DOSのメールソフトの場合 DOS側 インターネット側 本文 Shift_JIS <--> ISO-2022-JP (JIS) ヘッダ Shift_JIS <--> MIME "B" encoding 行の区切り CR LF <--> CR LF
どういう訳か、ISO-2022-JP (JIS)以外の文字コードが初期設定になっているソフトが実在します。無難とは言えないわけですが、イントラネット内での独自方式を想定していると言っているメーカもあります。
一方、行の区切りの設定はほとんど見かけません。最初からCR LFに変換するようになっていると思われます。
メールソフトではちゃんと読めるのに、メールを保存したファイルをテキストエディタ等で表示すると化けて見えることがあります。
これは変換前のファイルを見てるか、そのメールソフト独自の形式を見てるか、どっちかでしょう。[11] 文字化けすると、こう見える！参照
インターネットメッセージフォーマットは、もともとARPAというネットワークで使われていたものをRFC822という文書にまとめたものです。これはRFC1123で部分的に修正されました。
現在は、2001年4月に発行されたRFC2822に置き代わっています。
インターネットでメールを転送するためには、SMTP (Simple Mail Transfer Protocol)という方法を使います。
これはもともとASCIIを前提にしていたし、7ビットしか通さないような古いネットワークも考慮に入れていたので「8ビットは先頭ビットをゼロにしちゃえ」という事になっています。実際は8ビットがそのまま通るものも沢山あります。
その後、SMTPを拡張する方法が登場しました。これをESMTP (SMTP Service Extensions または Extended SMTP)と呼びます。最近のSMTPサーバは、この拡張機能が使えるものが多いです。
色々な拡張機能があり、例えば、
等です。どれとどれをサポートするかは、そのサーバ次第です。
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
という表現があります。
メールで色々な言語、音声、画像、動画等を扱えるようにした方法を MIME (Multipurpose Internet Mail Extensions)といいます。MIMEはRFC2045, 2046, 2047, 2048, 2049等に記載されています。
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ですから、それ以上変換する必要がありません。
X.400とは、CCITT (現ITU-T)というところが作り国際標準規格ISOになっている電子メールシステムの事です。インターネットメールとは別物ですから、ここでは説明していません。X.400とインターネットメール間で交換する方法については、RFC2156, 2157等に書かれています。
パソコン通信、イントラネット、一部のプロバイダ等では、ここで紹介したものとは異なる独自形式を使っているかもしれません。インターネットとの間を繋ぐマシンが、インターネット形式との変換をしている筈です。それぞれの管理者に問い合わせてください。
送信側と受信側の両方が、日本語メールに対応しなければなりません。日本語対応と書かれていないマシンやソフトでも可能かもしれませんが、十分な知識が必要になるでしょう。
途中で経由するサーバにはSMTP、ESMTP、POP、IMAP等がありますが、これらは「日本語対応」と書かれてなくても大丈夫です。
日本国外のパソコン通信、イントラネット、一部のプロバイダ等が、SMTPやESMTPじゃない独自形式だと面倒かもしれません。もしそれが日本語をサポートしてなかったら、正常な日本語メールを読み書き出来る可能性は低いでしょう。
これらの条件が整わない場合は、[12.6.2]を参考にしてください。