});メール転送プロトコルにはメール・フォーマットが前提にあるメールプロトコルについて解説する前に、インターネットで使用されるメールのフォーマットについて説明しよう。SMTP、POP、IMAPといったプロトコルが、インターネットメールの標準フォーマットを前提にしているからだ。インターネットメールのフォーマットは、基本となるインターネットメールのフォーマットに、MIMEと呼ばれる拡張形式を含めて確立されていると考えてよい(表1・2)。最初の標準化されたメールフォーマットがRFC561として発表される。MIMEの歴史年表なお、本連載では、RFC822(STD11)およびRFC2045からRFC2049までの最新のMIME仕様に準じて説明している。そのため、RFC2045からRFC2049によって置き換えられたRFC1521およびRFC1522とは異なる部分がある可能性があるので、その点は了解してほしい。Bodies(最初のMIME仕様。現在、多くの人がインターネットメールを利用している。このとき、本文のテキストだけのものから、ワープロや表計算ソフトのファイルを添付するものまで、さまざまなものがあるだろう。この利用方法を大ざっぱに分類すると、インターネットメールには、テキストを送る機能とテキスト以外のファイルを添付して送る機能があるといえる。インターネットメールは、もともとテキストベースのメールシステムであった。テキストしか送れないシステムである。英語圏で生まれたシステムのため、英語の使用が前提となっている。それではまず、テキストとテキスト以外では、何が異なっているのかを見ていこう。下の表3を見てほしい。これはASCIIコードと呼ばれる文字コード表である。ASCIIコード一覧。縦方向の並びが下位4bitsで、横方向の並びが上位4bitsを表している。>でくくられたコードは「制御コード」と呼ばれる。バックスペースによる一文字削除(<BS>)やベルを鳴らす(<BEL>)などの特殊な画面制御を示すASCIIコードは、おもに英語圏で使用される文字セット体系である(文字コードの表記では、US-ASCIIなどと示される)。一般にテキストとは、このASCIIコードのことをいう。文章で使われる「目に見える文字(可視コードという)」は、0x00から0x7fまでの範囲に分類されている。これがテキストの範囲となる。この領域以外は拡張域として「英語圏」では通常使用されていない。言い方を変えると、勝手に利用してもよい領域となる。ASCIIコードは8ビット中の下位7ビットまでしか使用していないため、「7ビットコード」とも呼ばれる。インターネットメールが送受信する際に前提とするのは、この範囲のコードだけである。現在では、それ以外のコードを送受信しても問題にならないことが多いが、メールサーバによっては受け付けないこともある。従って、仕様もそれを色濃く反映したものとなっている。可視コードではないフルビット(8ビット)で表現されたデータも当然存在する。ワープロや表計算ソフトなどのアプリケーション・データ(バイナリコード)や、日本語などの英語以外の言語コード(8ビットコード)がある場合だ。そこに、MIMEという仕様が登場するのである。MIMEには、次のことが定義されている。バイナリや8ビットコード・データなどの「コンテンツ」を、7ビットに変換する「可視コード化」の仕様(符号化)コンテンツをアプリケーションや言語と関連付けて格納する仕組み(構造化)つまり、MIMEによってあらゆるデータをテキスト(正確には、英語圏の人間にとってのテキスト)に変換して送受信しようとするのが、インターネットメールの根本的な考え方である。普段よく利用するインターネットメールへのファイルの添付とは、ファイルをテキスト化する作業のことになる。何とも時代錯誤の仕様であるが、これも古い歴史を持ったプロトコルのための特徴といえるだろう。メール・フォーマットの概要ここでは、一般的なインターネットメールのフォーマットから見てみることにしよう。下の図1は、インターネットメールの模式図である。この例では、最もシンプルなメール形式、単純なテキストだけのメールである(つまりMIMEメールではない)。シンプルなメールの例HTTPメッセージのように、インターネットメールのメールメッセージも、ヘッダとボディとに分けられる。ボディは、実際に送受信したいメールの本文となる。これは、はがきの裏に書く本文に当たる。ヘッダは、あて先や差出人、そのほか配達に必要な情報を表している。はがきの表書きに当たる。両者の境界は、空行によって見分けることが可能だ。ヘッダは、ヘッダ・フィールドと呼ばれる行によって構成されている。行の終端はCR(キャリッジリターン:16進の0x0d)とLF(ラインフィード:16進の0x0a)によって示される。続く行の先頭が空白か水平タブ(0x09)の場合は、前行からの続きであると見なされる。各行の最大文字数は、通常70から80文字までに制限される。この制限を超える場合には、複数行に分割しなければならない。フィールドは、次のようなフォーマットとなる。パラメータ名=パラメータ値]フィールド名が示す内容がフィールド値である。フィールドによっては、「;」(セミコロン)で区切られた複数のパラメータが続く場合がある。パラメータは、フィールドを補足するための値である。前回までの本連載を読まれた読者は、ヘッダからフォーマットまで、考え方はHTTPメッセージとまったく同じであることに気づかれただろう。それでは、実際のヘッダの中身を見てみよう。おもなヘッダの種類はRFC821などに定義されている。メールのヘッダ定義は基本的なもの以外にも、機能を追加するため、別の仕様としてさまざまな標準仕様が追加されたもの、標準仕様にはないが、歴史的な経緯によって利用されてきたものなどがあり、非常に複雑である。そこで、普段よく使われるヘッダを標準/非標準問わず一覧で解説しているRFC2076がある*1。すべてのヘッダが掲載されているわけではないが、ぜひ参考にしてほしい。先頭が「X-」で始まるフィールドは、メーラなどのアプリケーションが独自に採用したもので、自由に含めてもよい。ほとんどの場合、アプリケーション固有のもので互換性はないが、なかには有名になり、多くのアプリケーションが共通して採用しているものもある。Fromはメールの差出人、Toはあて先、そしてccはCC(カーボンコピー)先を表す。複数のあて先やCC先を指定する場合は、「,」(カンマ)でアドレスをくくる。ここで、Bcc(ブラインド・カーボンコピー)が存在するのを意外に思う読者がいるかもしれない。このフィールドがメールに残っていたら、Bccの意味をなさないからだ。実はメールの送信時にはBccフィールドがあっても、メールサーバが転送するときに取り除いてしまうのである。送信時にのみ存在する特殊なフィールドである。SenderはFromに似ているが、「実際の送信者」を示す。Fromには差し出しに同意したグループメンバー全員のアドレスを入れ、Senderには実際に出した人のアドレスを入れるような場合を想定している。そのため、Senderのアドレスは1つしか入れられないことになっている。Reply-Toは返信先である。このフィールドがないと、メーラは通常返信メールのあて先をFromのアドレスだと判断する。上で述べたように厳密にいうとFromは差出人ではない。メールを出したアドレスとは別のアドレスに返信してほしいことがある。そのような場合に、Reply-Toをあらかじめ指定しておく。そのほか、頻出するヘッダを別表にまとめておいたので、参考にしてほしい(ここをクリックすると、別ウィンドウでメールヘッダの一覧を表示します)。*1RFC2076には、メールのヘッダと同時にネットニュース(Usenet:NNTPで利用されるインターネットニュース)で使用するヘッダも同時に記載されている。これは、ニュースではメールとほぼ同様のフォーマットを使用するため。RFC2076に一度は目を通してほしい。現在ではほとんど使われなくなったヘッダも含めて、さまざまなヘッダがあり得ることが実感できるからだ。それらのヘッダは、これまでのメールが歩んできた紛れもない歴史の一端であるのだMIMEとメディアタイプそれでは、実際にMIMEメールを見てみよう。次のリスト1は、メールに本文はなく、画像ファイルを1つだけ添付した例だ。普通のメールと変わらないように見えるが、MIMEにかかわるヘッダが幾つかあるのがわかる。MIME-Version:MIMEのバージョン番号を示す。現在は1.0しか存在しない。パージョン番号Content-Type:「メディアタイプ」と呼ばれるボディ部分の属性を示すヘッダだ。MIMEのコア部分のヘッダである。ここで、MIMEの「構造化」機能を提供する。等のパラメータ]MIMEは、さまざまな添付ファイルを格納する可能性がある。データを単に受け取っただけでは、メールの受信者は何のファイルで、どのアプリケーションを使って開けばよいのかわからない。そこで、データのタイプを指定して受信者に教えるのがこのヘッダである。タイプでアプリケーション種別の大項目を、サブタイプで詳細を示す*2。*2ファイルから関連したアプリケーションのタイプを知るだけなら、拡張子を見ればわかるという声が、Windowsユーザーから聞こえてきそうだ。拡張子はすべてのOSに共通したものではない。そこで、OSに依存しないメディアタイプのような方法が必要となるのであるタイプには、次の8つが定義されており、トップレベル・メディアタイプと呼ばれることもある。(1)text一般的なテキストファイルやHTMLファイル、リッチテキストなど(2)applicationアプリケーションのデータファイル。ワープロや表計算ソフトのファイルなど(3)imageGIFやJPEGなどの画像ファイル(4)audioWAVEやAUなどの音声ファイル(5)videoMPEGやQuickTimeなどの動画ファイル(6)model2Dや3Dグラフィックスのためのオブジェクト・データ。RFC2077で追加されたもの(7)messageRFC822に準拠したメール・メッセージなど(8)multipartマルチパート型メッセージ見るとわかるが、メールに添付しそうなファイルの種別はほとんど網羅されている。messageは、メールなどのメッセージを指す。ボディとして別のメール・メッセージそのものを含むなど、複雑な場合に必要となるタイプである。multipartについては後編で詳しく説明するが、messageとmultipartは複数のファイルから構成されるタイプのため、複合タイプと呼ばれることがある。サブタイプは、具体的なアプリケーションやデータの種別となる。Authority)が登録と管理を行っており、民間からの任意申請も可能だ。登録方法はRFC2048で解説されている。そのため、自社のアプリケーション用に、さまざまなベンダーが登録している。別表に、原稿アップ時点で定義されているタイプとサブタイプの対象表を掲載した(ここをクリックすると別ウィンドウでタイプ/サブタイプの一覧を表示します)。最新のタイプ/サブタイプは、ここから入手できる。Wordなどのアプリケーションまで、さまざまなタイプがあるのがわかる。メーラは、内部でこのタイプ/サブタイプと対応アプリケーションの対照表を管理しており、必要に応じて対応アプリケーションを起動させることになる。アプリケーションが特定できない場合などには、application/octet−streamという汎用的なタイプが指定される。受信側はほかの付属ヘッダなどからタイプを推測することになる。さまざまなContent-Typeの例また、各タイプ/サブタイプごとに、必要なパラメータを取ることがある。パラメータは、メッセージへの付加的な情報を示している。charset=文字コードとすることで、テキストの文字コードを示すことができる。Content-Description/Content-Dispositionこの2つは、MIMEヘッダによく使用される。Content-Descriptionは、一種のコメント域となる。次のように使用される。Picture(BMP)"Content-Dispositionは、ボディに含まれるファイルなどのデータの属性を指定する。ヘッダ値として取られるinlineは、メール本文など、そのほかの要素と一緒に表示することをメーラに指示する。attachmentは、通常の添付ファイルとしての扱いを示す。強制力を伴わないが、送信側の意図を伝える意味で使用される。filenameパラメータを用いて、オリジナルの添付ファイル名を伝えることも大きな目的である。Content-Transfer-Encoding:実際のデータの格納方法を示すのがこのフィールドだ。格納方法とは、ほとんどの場合はテキストへの変換(「可視コード化」とも呼ぶ)を指す。MIMEの「符号化」機能を提供する。格納方法には、以下のものがある。●7bitボディがもともと7ビットのテキストコードであることを示す●8bitボディが8ビットのテキストコードであることを示す●binaryテキスト以外のバイナリ・データ。Printable形式データ。7ビット●base64Base64形式データ。7ビット8ビット(8bits)とバイナリ(binary)が定義されている点に注意してほしい。最近インターネットメールを8ビット・データに対応させようという動きがあるが、その際に8ビットのままで利用するための定義である。した活動は限定的なもので、厳密にはこの2つの方法は仕様違反だと思ってほしい。そのため、われわれが目にするのはほとんどが7ビットとbase64となるはずだ。この例では、Base64が指定されている。Base64の詳細はコラムを参照してほしいが、要するに8ビット・データを何とか7ビット・データにする方法のことである。これをエンコード*3と呼ぶ。現在の最新メーラであれば、画像や動画、アプリケーション・データは、ほとんどBase64でエンコードされているはずだ。そのほかについては、別表を参照してほしい(ここをクリックすると別ウィンドウでMIME関連のメールヘッダの一覧を表示します)。*3具体的に解説すると、ここでいうエンコードとは、圧縮のことを指しているわけではない。実際には、圧縮どころか、ファイルサイズが大きくなることのほうが多い。単なるコード変換でしかないエンコード形式の種類メールに限らないが、インターネット・プロトコルではバイナリ・データから7ビット・データへ変換するエンコード手法がよく利用される。その目的は本文で説明したとおりだが、テキスト化という意味から「可視化」とも呼ばれる。ここでは、おもなエンコード形式を紹介しよう。●Base64バイナリ・データから3バイトずつ切り出し、これらを6ビット(10進では0から63に該当する)ごとに64種類のASCIIコードへそれぞれ割り当てていくエンコード方法のこと。元データの3バイトが4バイトに変換されることになるので、サイズは約1.3倍になる。すべて元データがぴったり3バイトごとに割り切れるわけではない。そこで足りない部分にはパディングとして、「=」(イコール)を付加する。/例えば、「@IT」(シフトJIS)は、16進では次のようになる。0x73そのため、Base64では次のように表現できる。PrintableASCII文字(=(イコール)を除く)、空白、水平タブ以外を次のように表記する。「@IT」であれば、次のとおりになる。=81=97=82=68=82=73ASCIIコード以外のデータが多少混ざる程度のデータであれば効率的だが、通常のバイナリであればBase64のほうがサイズは格段に小さくなる。Printableは欧米でよく使われるが、日本ではあまり使われない傾向にあるようだ。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。