MIME（Multipurpose Internet Mail Extensions）〜前編：インターネット・プロトコル詳説（3）

メール転送プロトコルにはメール・フォーマットが前提にある

　メールプロトコルについて解説する前に、インターネットで使用されるメールのフォーマットについて説明しよう。なぜなら、SMTP、POP、IMAPといったプロトコルが、インターネットメールの標準フォーマットを前提にしているからだ。

　インターネットメールのフォーマットは、基本となるインターネットメールのフォーマットに、MIMEと呼ばれる拡張形式を含めて確立されていると考えてよい（表1・2）。

　なお、本連載では、RFC822（STD11）およびRFC2045からRFC2049までの最新のMIME仕様に準じて説明している。そのため、RFC2045からRFC2049によって置き換えられたRFC1521およびRFC1522とは異なる部分がある可能性があるので、その点は了解してほしい。

すべてのメールはテキスト形式

　現在、多くの人がインターネットメールを利用している。このとき、本文のテキストだけのものから、ワープロや表計算ソフトのファイルを添付するものまで、さまざまなものがあるだろう。この利用方法を大ざっぱに分類すると、インターネットメールには、テキストを送る機能とテキスト以外のファイルを添付して送る機能があるといえる。

　インターネットメールは、もともとテキストベースのメールシステムであった。つまり、テキストしか送れないシステムである。さらに、英語圏で生まれたシステムのため、英語の使用が前提となっている。

　それではまず、テキストとテキスト以外では、何が異なっているのかを見ていこう。まず、下の表3を見てほしい。これはASCIIコードと呼ばれる文字コード表である。

　 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をあらかじめ指定しておく。

　そのほか、頻出するヘッダを別表にまとめておいたので、参考にしてほしい（ここをクリックすると、別ウィンドウでメールヘッダの一覧を表示します）。

MIMEとメディアタイプ

　それでは、実際にMIMEメールを見てみよう。次のリスト1は、メールに本文はなく、画像ファイルを1つだけ添付した例だ。

Return-Path: taro@anywhare.**.jp
Received: from smtp.anywhare.**.jp (smtp.anywhare.**.jp [219.219.219.1])
  by smtp1.kaisya.**.jp (8.8.8/8.8.8) with ESMTP id 
EAA13892;
  Mon, 19 Feb 2001 05:47:59 +0900 (JST)
  (envelope-from taro@anywhare.**.jp)
Received: from taropc (taropc.anywhare.**.jp [219.199.199.199]) 
  by smtp.anywhare.**.jp (8.9.3/3.7W) with ESMTP id 
EAA26267
  ; Mon, 19 Feb 2001 05:48:31 +0900 (JST)
Date: Mon, 19 Feb 2001 05:46:28 +0900
From: "Taro Yamada" <taro@anywhare.**.jp>
To: "Hanako Suzuki" <hanako@kaisya.**.jp>
Subject: 画像です
Message-Id: <20010219054950.8032@anywhare.**.jp>MIME-Version: 1.0
Content-Type: image/gif;
  name="＠ＩＴロゴマーク.gi
  f"
Content-Disposition: attachment;
  filename="＠ＩＴロゴマーク.gi
  f"
Content-Transfer-Encoding: base64
X-Mailer: Becky! ver. 2.00
X-UIDL: c77a7ce4659ef0977f1ec2cc1574344b 
R0lGODlhcwA4AOYAAP/////++Pj9+/749fn49/H2+eX27+/v7+H07N3z6eXs8dXw5OLl6N/l68/u
4Nfi7Mjs3NXe5sTq2tjb4L3n1bjm0tDY4czY5bTkz67iy8jS3Krgx8zMzKXexMHI1Jrbv7fG1rnE
0JbZvJDXt7i/x4vWta29zobUsqS70ofRrKu4xaS3y3zQq6S0xaCzx3LMpZyvw52vwW7LombMmZSq
（中略）
4uBHAgEU4AtnLGTjaJlIMsDBBcaoIS+5QAxgNq6HALjBF1VgAwA04Ixo4GIxQOBMMhwRAEWQJiV+
0wM40rN+Q/SA9baJRCAor3smWEERVGDG3bVABVcYpA1U8IQhqKAIT2Ao964AAhoAQQVDGGQMVFCF
QZJhpFU4ggogyEseqACGj0Pp+dDwhje0IQ6vfFwc4mDSN8RhDTfNHk4ft4aa+rSelPCpScmgVDYM
VYVxGKjjlEqJQAAAOw==

　普通のメールと変わらないように見えるが、MIMEにかかわるヘッダが幾つかあるのがわかる。

MIME-Version：

　MIMEのバージョン番号を示す。現在は1.0しか存在しない。

Content-Type：

　「メディアタイプ」と呼ばれるボディ部分の属性を示すヘッダだ。MIMEのコア部分のヘッダである。ここで、MIMEの「構造化」機能を提供する。

　MIMEは、さまざまな添付ファイルを格納する可能性がある。データを単に受け取っただけでは、メールの受信者は何のファイルで、どのアプリケーションを使って開けばよいのかわからない。そこで、データのタイプを指定して受信者に教えるのがこのヘッダである。タイプでアプリケーション種別の大項目を、サブタイプで詳細を示す^＊2。

　タイプには、次の8つが定義されており、トップレベル・メディアタイプと呼ばれることもある。

（1）text
　一般的なテキストファイルやHTMLファイル、リッチテキストなど

（2）application
　アプリケーションのデータファイル。ワープロや表計算ソフトのファイルなど

（3）image
　GIFやJPEGなどの画像ファイル

（4）audio
　WAVEやAUなどの音声ファイル

（5）video
　MPEGやQuickTimeなどの動画ファイル

（6）model
　2Dや3Dグラフィックスのためのオブジェクト・データ。RFC2077で追加されたもの

（7）message
　RFC822に準拠したメール・メッセージなど

（8）multipart
　マルチパート型メッセージ

　見るとわかるが、メールに添付しそうなファイルの種別はほとんど網羅されている。messageは、メールなどのメッセージを指す。つまり、ボディとして別のメール・メッセージそのものを含むなど、複雑な場合に必要となるタイプである。multipartについては後編で詳しく説明するが、messageとmultipartは複数のファイルから構成されるタイプのため、複合タイプと呼ばれることがある。

　サブタイプは、具体的なアプリケーションやデータの種別となる。IANA（Internet Assigned Number Authority）が登録と管理を行っており、民間からの任意申請も可能だ。登録方法はRFC2048で解説されている。

　そのため、自社のアプリケーション用に、さまざまなベンダーが登録している。別表に、原稿アップ時点で定義されているタイプとサブタイプの対象表を掲載した（ここをクリックすると別ウィンドウでタイプ／サブタイプの一覧を表示します）。また、最新のタイプ／サブタイプは、ここから入手できる。

　これを見ると、HTMLやGIFなどのオーソドックスなタイプから、見慣れたMicrosoft Wordなどのアプリケーションまで、さまざまなタイプがあるのがわかる。メーラは、内部でこのタイプ／サブタイプと対応アプリケーションの対照表を管理しており、必要に応じて対応アプリケーションを起動させることになる。

　アプリケーションが特定できない場合などには、application/octet−streamという汎用的なタイプが指定される。受信側はほかの付属ヘッダなどからタイプを推測することになる。

　また、各タイプ／サブタイプごとに、必要なパラメータを取ることがある。パラメータは、メッセージへの付加的な情報を示している。

　例えば、text/plainは通常のテキストを示しているが、

とすることで、テキストの文字コードを示すことができる。

Content-Description／Content-Disposition

　この2つは、MIMEヘッダによく使用される。Content-Descriptionは、一種のコメント域となる。例えば、次のように使用される。

　Content-Dispositionは、ボディに含まれるファイルなどのデータの属性を指定する 。

　ヘッダ値として取られるinlineは、メール本文など、そのほかの要素と一緒に表示することをメーラに指示する。attachmentは、通常の添付ファイルとしての扱いを示す。必ずしも強制力を伴わないが、送信側の意図を伝える意味で使用される。さらにfilenameパラメータを用いて、オリジナルの添付ファイル名を伝えることも大きな目的である。

Content-Transfer-Encoding：

　実際のデータの格納方法を示すのがこのフィールドだ。格納方法とは、ほとんどの場合はテキストへの変換（「可視コード化」とも呼ぶ）を指す。つまり、MIMEの「符号化」機能を提供する。

　格納方法には、以下のものがある。

　8ビット（8bits）とバイナリ（binary）が定義されている点に注意してほしい。最近インターネットメールを8ビット・データに対応させようという動きがあるが、その際に8ビットのままで利用するための定義である。しかし、こうした活動は限定的なもので、厳密にはこの2つの方法は仕様違反だと思ってほしい。そのため、われわれが目にするのはほとんどが7ビットとbase64となるはずだ。

　この例では、Base64が指定されている。Base64の詳細はコラムを参照してほしいが、要するに8ビット・データを何とか7ビット・データにする方法のことである。これをエンコード^＊3と呼ぶ。現在の最新メーラであれば、画像や動画、アプリケーション・データは、ほとんどBase64でエンコードされているはずだ。

　そのほかについては、別表を参照してほしい（ここをクリックすると別ウィンドウでMIME関連のメールヘッダの一覧を表示します）。