RFC 2049: MIME Part 5 — 適合性基準と例

Standards Track MIME — Multipurpose Internet Mail Extensions Published March 2026

ELI5: RFC 2045–2047はMIMEのルールを定義しています。RFC 2049は試験です：ソフトウェアが「MIME準拠」として認められるために何をしなければならないかを正確に規定し、実装をチェックするための具体的な例を提供しています。MIMEが建築基準法であれば、これが検査チェックリストです。

このドキュメントが存在する理由

MIME仕様は4つの技術RFC（2045、2046、2047、および2048）にまたがっています。実装者は「MIMEに準拠するためにソフトウェアが最低限処理する必要があるものは何か？」という明確な答えが必要です。RFC 2049はその答えを提供し、実装者がパーサを検証するために使用できる正規テストメッセージも含みます。

準拠文書がなければ、異なる実装がMIMEの異なるサブセットをサポートし、相互運用性の障害につながります。RFC 2049は最低基準を定めています。あらゆるMIMA対応システムは、少なくともこれらのコンテンツタイプ、エンコーディング、および構造を処理する必要があります。

仕組み

RFC 2049は2つのレベルの準拠を定義し、それぞれ特定の要件があります。

送信エージェント要件

MIME準拠送信エージェント（MUAまたはメールライブラリ）は、次の条件を満たす必要があります。

MIME機能を使用するすべてのメッセージにMIME-Version: 1.0を常に含める
本文が単純な米国ASCII以外のテキストである場合、Content-Typeヘッダを含める
有効なContent-Transfer-Encodingを使用する。これにより、メッセージ本文が7ビットSMTPゲートウェイを通じて確実に存続できます（非ASCIIコンテンツの場合はbase64またはquoted-printable）。
ヘッダフィールドを正しくエンコードする。SubjectやFrom表示名などのヘッダに非ASCII文字が現れる場合は、RFC 2047エンコード単語を使用します。
有効なマルチパートバウンダリを生成する。このバウンダリは、含まれるボディパートには現れてはいけません。

受信エージェント要件

MIME準拠受信エージェントは、次の条件を満たす必要があります。

MIME-Version: 1.0を認識し、メッセージをMIMEエンコードとして扱う
Content-TypeおよびContent-Transfer-Encodingヘッダをすべてのパラメータを含めて解析する
base64およびquoted-printableコンテンツ転送エンコーディングをデコードする
すべてのマルチパートタイプを処理する。最低限multipart/mixed、multipart/alternative、multipart/digest、multipart/parallel。不明なマルチパートサブタイプはmultipart/mixedとして扱われるべきです。
message/rfc822を処理する。カプセル化されたメッセージを表示するか、少なくとも保存オプションを提供します。
認識されないコンテンツタイプを適切に処理する。ボディパートをファイルとして保存するオプションを提供します。クラッシュしたり無視したりしません。認識されないタイプはapplication/octet-streamとして扱うべきです。
RFC 2047エンコード単語をヘッダフィールドでデコードする
テキストタイプのcharsetパラメータを処理する。最低限US-ASCIIとISO-8859-1をサポートし、理想的にはUTF-8をサポートします。

堅牢性原則

RFC 2049はMIMEに対するPostels法を強化しています。送信時に厳密に、受信時に寛容に。準拠受信者は、わずかに形式が不正なMIMEメッセージであっても表示するため最善を尽くすべきです。完全に拒否する代わりに。

主な技術詳細

正規例

RFC 2049には作業済みMIMEメッセージの例が含まれています。プレーンテキストとHTMLの両方を含む適切なマルチパート/alternative メッセージのパターンはここにあります。

MIME-Version: 1.0
From: sender@example.com
To: recipient@example.com
Subject: MIME conformance test
Content-Type: multipart/alternative; boundary="boundary42"

--boundary42
Content-Type: text/plain; charset=us-ascii

This is the plain text version.

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

<html><body><p>This is the <strong>HTML</strong> version.</p></body></html>

--boundary42--

不明なタイプの処理

重要な準拠要件。受信エージェントが理解できないContent-Typeに遭遇した場合、application/octet-streamとして扱い、保存オプションを提供する必要があります。このルールは将来互換性を保証しています。新しいメディアタイプは既存クライアントを破壊することなく定義できます。

; Unknown type encountered by a client
Content-Type: application/vnd.custom-format
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="data.custom"

; Conformant client treats this as application/octet-stream
; and offers the user a "Save As" dialog

不明なマルチパートサブタイプ

同様に、不明なマルチパートサブタイプはmultipart/mixedとして扱う必要があります。これは、クライアントが各パートを順序付けて表示することを意味します。たとえば、multipart/report（後でRFC 3462で定義）は、これを混合型として扱う古いクライアントでも正しく表示されます。

最小文字セットサポート

準拠実装は最低限以下をサポートする必要があります。

US-ASCII。基線です
ISO-8859-1。西ヨーロッパ文字（Latin-1）

実際には、モダン実装はUTF-8をサポートする必要があります。2024年以降これを行わないことは、技術仕様が義務付けていなくても、精神的には準拠の失敗です。

MIME/非MIME境界

MIME-Version: 1.0ヘッダなしのメッセージは、Content-Typeヘッダが含まれているかどうかに関わらず、プリMIMEプレーンASCIIテキストとして扱われます。MIMEバージョンヘッダはゲートキーパーです。それなしでは、MIME処理は活性化されません。

一般的な間違い

不明なContent-Typesでクラッシュする。 仕様は明確です。不明なタイプをapplication/octet-streamとして扱います。不明なタイプで例外をスローするライブラリは準拠せず、新しいメディアタイプが登録されると破壊されます。
不明なマルチパートサブタイプをエラーとして扱う。 それらはmultipart/mixedとして扱うべきです。一般的なバグはmultipart/report、multipart/signed、または他の拡張タイプを拒否またはスキップすることです。
text/*タイプで文字セットを無視する。 文字セット宣言なしのテキストコンテンツはデフォルトでUS-ASCIIです。UTF-8として表示するとASCIIコンテンツでは機能しますが、レガシーISO-8859-1メッセージでは文字化けが生じます。
転送されたメッセージからMIME-Versionを削除する。 転送または再送信する場合、MIMEバージョンヘッダを保持する必要があります。それなしでは、受信クライアントがMIME構造をまったく処理しないかもしれません。
部分的なbase64/QPデコード。 両方のデコーダは境界ケースを処理する必要があります。base64パディング、QPソフト行区切り（=\r\n）、および末尾の空白。不完全なデコーダは正規メッセージで破損した出力を生成します。
表示不可パートの保存オプションを提供しない。 準拠クライアントは、表示できない場合でもボディパートの保存をユーザーに許可する必要があります。パートを無視することは仕様に違反しデータを失います。

配信可能性への影響

準拠MIME構造は配信可能性の基線です。 非準拠メッセージ。MIMEバージョンなし、破損マルチパートバウンダリ、不正なエンコーディング。スパムツールの特徴です。スパムフィルタはMIME準拠を品質シグナルとして使用します。
text/plainとtext/htmlの両方を含めます。 RFC 2049の例は両形式のmultipart/alternativeを示します。これは単なる良い慣行ではなく、多くのスパムフィルタはHTML専用メッセージにペナルティを与えます。text/plainパートは「このメールをブラウザで表示」ではなく、意味のあるコンテンツである必要があります。
有効なContent-Transfer-Encodingは破損を防ぎます。 quoted-printableを宣言するが、生の8ビットデータを含むメッセージは、7ビットSMTPゲートウェイで破損します。これはメッセージがインボックスに到達しても、受信者でレンダリング失敗を引き起こします。
正しい文字セット宣言は文字化けを防ぎます。 UTF-8コンテンツに対してcharset=us-asciiを宣言するとアクセント文字が読み取り不可になります。受信者はデコードを試みるのではなく、メッセージをスパムとして報告するかもしれません。
形式の正しいMIMEはクライアント全体でレンダリングを改善します。 MIME準拠メッセージはGmail、Outlook、Apple Mail、Thunderbird、およびモバイルクライアントで正しくレンダリングされます。非準拠メッセージは1つのクライアントでレンダリングされる可能性がありますが、別のクライアントで破壊されて、苦情と登録解除を引き起こす可能性があります。