← RFC Reference

RFC 2045: MIME パート1 — インターネットメッセージボディのフォーマット

なぜこれが存在するのか

RFC 5322（およびその前身のRFC 822）は、メールメッセージをプレーンなUS-ASCIIテキストで定義し、最大行長を998文字としていました。1982年には問題ありませんでしたが、現代のメールには対応していません。現代のメールには以下が必要です：

• 非ASCIIキャラクターセット（UTF-8、ISO-8859-*など）のテキスト
• インラインスタイルと画像を含むHTMLコンテンツ
• ファイル添付（PDF、画像、アーカイブ）
• 複数ボディパーツ（1つのメッセージ内にテキスト＋HTML＋添付ファイル）

MIME（Multipurpose Internet Mail Extensions）は、元のASCIIのみのインフラとの後方互換性を保ちながら、これらすべてに対応するために5つのRFCを拡張したスイートです。RFC 2045はパート1で、他のすべてを可能にするヘッダーフィールドとエンコーディングメカニズムを定義しています。

動作方法

RFC 2045は、3つの重要なヘッダーフィールドと2つのエンコーディングスキームを導入しています。

MIME-Versionヘッダー

すべてのMIMEメッセージは以下を含む必要があります：

MIME-Version: 1.0

これは、受信メールクライアントにメッセージがMIME規約を使用していることを通知します。このヘッダーがない場合、メッセージはRFC 5322に従ってプレーンなUS-ASCIIテキストとして扱われます。バージョンは1996年以来1.0のままで、変更されたことはありません。

Content-Typeヘッダー

ボディのメディアタイプとサブタイプ、およびオプションのパラメータを宣言します：

Content-Type: type/subtype; parameter=value

例：

; UTF-8のプレーンテキストメール
Content-Type: text/plain; charset=utf-8

; HTMLメール
Content-Type: text/html; charset=utf-8

; PDF添付ファイル
Content-Type: application/pdf; name="invoice.pdf"

; マルチパートメッセージ（テキスト+HTML+添付ファイル）
Content-Type: multipart/mixed; boundary="----=_Part_123"

Content-Typeが存在しない場合、デフォルトはtext/plain; charset=us-asciiです。これはMIME前のメッセージとの後方互換性を保ちます。

Content-Transfer-Encodingヘッダー

SMTPは、行長が998文字以下の7ビットASCIIテキストを運ぶために設計されていました。バイナリデータ（画像、PDF）と8ビットテキスト（UTF-8）は、これらの制約に合わせるようにエンコードする必要があります。RFC 2045は5つの転送エンコーディングを定義しています：

Quoted-Printableエンコーディング

ほとんどがASCIIで、たまに非ASCIIキャラクターがあるテキスト向けに設計されています。各非ASCIIバイトは=XXとしてエンコードされます。ここで、XXは16進値です。76文字を超える行は、末尾の=でソフトラップされます。

; オリジナル：「René sent the café menu」
Content-Transfer-Encoding: quoted-printable

Ren=C3=A9 sent the caf=C3=A9 menu

=C3=A9は、é（U+00E9）のUTF-8エンコーディングで、各バイトが16進エンコードされています。

Base64エンコーディング

任意のバイナリデータをASCIIキャラクター（A-Z、a-z、0-9、+、/）にエンコードします。入力の3バイトごとに、4つのASCIIキャラクターになります。行は76文字でラップされます。

Content-Type: image/png; name="logo.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34
AAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAAApgAAAKYB
zN+OGwAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBl

重要な技術的詳細

Content-Dispositionヘッダー

RFC 2045自体の一部ではありませんが（RFC 2183から）、Content-Dispositionはこれと密接に関連し、MIMEで広く使用されています：

; インラインで表示（例：埋め込み画像）
Content-Disposition: inline

; ダウンロード可能な添付ファイルとして提供
Content-Disposition: attachment; filename="report.pdf"

完全なMIMEメッセージ

すべてをまとめます。テキストボディとHTMLボディ、および添付ファイルを含むメッセージ：

MIME-Version: 1.0
From: sender@example.com
To: recipient@example.com
Subject: Invoice attached
Content-Type: multipart/mixed; boundary="----=_outer"

------=_outer
Content-Type: multipart/alternative; boundary="----=_inner"

------=_inner
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Please find your invoice attached.

------=_inner
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<p>Please find your invoice attached.</p>

------=_inner--
------=_outer
Content-Type: application/pdf; name="invoice.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="invoice.pdf"

JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PCAvVHlwZSAv
Q2F0YWxvZyAvUGFnZXMgMiAwIFIgPj4KZW5kb2JqCg==

------=_outer--

構造に注意してください：multipart/mixedはボディと添付ファイルを保持します。ボディ自体はmultipart/alternativeでテキスト版とHTML版があります。マルチパートタイプの詳細については、RFC 2046を参照してください。

Charsetパラメータ

text/*タイプのcharsetパラメータは、文字エンコーディングを宣言します。最新のメールでは、常にutf-8を使用してください：

Content-Type: text/plain; charset=utf-8
Content-Type: text/html; charset=utf-8

iso-8859-1、windows-1252、shift_jisなどのレガシーチャーセットはまだ見られますが、新しいメッセージでは使用しないでください。

よくある間違い

• MIME-Version: 1.0の欠落。このヘッダーがない場合、一部のメールクライアントはContent-Typeを無視し、ボディをプレーンASCIIテキストとして扱います。HTMLメールは生のソースコードとして表示されます。
• バイナリデータの間違ったContent-Transfer-Encoding。バイナリ添付ファイルを7bitエンコーディングで送信すると、破損します。ヌルバイトと高ビット文字が壊れます。バイナリコンテンツでは常にbase64を使用してください。
• 不足または間違ったcharsetパラメータ。charsetを省略すると、us-asciiにデフォルト設定されます。テキストにUTF-8文字が含まれている場合、それらはガベージとして表示されます。常にcharset=utf-8を宣言してください。
• 998文字を超える行。RFC 5322は998文字の行制限を義務付けています。Base64は76文字でラップされます。Quoted-printableはソフト行改行を使用します。生の8ビットテキストも、この制限を遵守する必要があります。そうしないと、中間サーバーがメッセージを切り詰めるか拒否する可能性があります。
• サーバーサポートを確認せずに8bitを使用。8bitエンコーディングでは、受信サーバーがEHLOレスポンスで8BITMIMEをアナウンスする必要があります。サーバーがサポートしていない場合は、quoted-printableまたはbase64を使用してください。
• ボディコンテンツに現れるバウンダリ文字列。マルチパートバウンダリはボディパートに現れてはいけません。衝突を避けるために、長い、ランダムなバウンダリ文字列を使用してください。

配信性への影響

• 適切なMIME構造は交渉の余地がありません。形式が不正なMIMEはスパムフィルターをトリガーします。不足したMIME-Version、不正なバウンダリ、または間違ったエンコーディングはすべて、スパムフィルターが探す赤信号です。
• 常にmultipart/alternativeを送信します。text/plainとtext/htmlパートの両方を含めます。HTMLのみのメッセージは、多くのスパムフィルターによって処罰されます。テキストパートはプレーンテキストクライアント用のフォールバックとしても機能します。
• 添付ファイルにはbase64、テキストにはquoted-printableを使用します。これはユニバーサルに互換性のある組み合わせです。あらゆるSMTPサーバーとメールクライアント全体で機能します。
• 添付ファイルのサイズを妥当に保ちます。Base64エンコーディングは33%のオーバーヘッドを追加します。7.5 MBのファイルは10 MBのメールになります。多くのサーバーは25 MBを超えるメッセージを拒否します。一部は10 MBを超えて拒否します。
• 文字セットの正確性はレンダリング障害を防ぎます。charset=utf-8を宣言し、実際にUTF-8でエンコードすると、メールが世界中で正しくレンダリングされます。文字セット宣言の不一致は、文字化け（ガベージテキスト）とサポートの苦情につながります。

Related RFCs