1. Introduction (はじめに)
1.1. Scope (範囲)
本文書は、インターネットメッセージ形式 (IMF, Internet Message Format) を定義します。これは、「電子メール」メッセージのフレームワーク内で、コンピュータユーザー間で送信されるテキストメッセージの構文です。本仕様は RFC 2822 の改訂版であり、RFC 2822 自体が RFC 822 に取って代わり、現在の慣行を反映するように更新し、他の RFC で指定された増分変更を組み込んでいます。
本文書はテキストメッセージの構文のみを規定します。特に、電子メールメッセージにおける画像、音声、その他の種類の構造化データの送信については規定していません。MIME 文書シリーズ (RFC 2045、RFC 2046、RFC 2049) などのいくつかの拡張が公開されており、電子メールを通じてこのようなデータを送信するメカニズムが記述されています。
電子メールの文脈では、メッセージはエンベロープ (Envelope) とコンテンツ (Contents) を持つものと見なされます。エンベロープには、送信と配信を達成するために必要な情報が含まれます (エンベロープについては RFC 5321 を参照)。コンテンツは、受信者に配信されるオブジェクトで構成されます。本仕様は、メッセージコンテンツの形式と一部のセマンティクスにのみ適用されます。エンベロープ内の情報の仕様は含まれていません。
ただし、一部のメッセージシステムは、コンテンツからの情報を使用してエンベロープを作成する場合があります。本仕様は、プログラムがこのような情報を取得することを容易にすることを意図しています。
本仕様は、システム間で渡されるメッセージコンテンツ形式の定義として意図されています。一部のメッセージシステムはこの形式でメッセージをローカルに保存しますが (形式間の変換の必要性を排除)、他のシステムは異なるネイティブ形式を使用します。ローカルストレージは本仕様の範囲外です。
注意: 本仕様は、サイトで使用される内部形式、サポートが期待される特定のメッセージシステム機能、またはメッセージを作成または読み取るユーザーインターフェースプログラムの特性を規定することを意図していません。さらに、本文書は送信または保存に使用される文字エンコーディングを指定していません。
1.2. Notational Conventions (表記規則)
1.2.1. Requirements Notation (要件表記法)
本文書では、大文字で表示される用語が時々使用されます。「MUST」、「SHOULD」、「RECOMMENDED」、「MUST NOT」、「SHOULD NOT」、および「MAY」という用語が大文字で表示される場合、本仕様の特定の要件を示すために使用されています。これらの用語の意味については、RFC 2119 を参照してください。
キーワード参照:
| 用語 | 意味 |
|---|---|
| MUST | しなければならない (絶対要件) |
| MUST NOT | してはならない (絶対禁止) |
| SHOULD | すべきである (強い推奨) |
| SHOULD NOT | すべきでない (強い非推奨) |
| RECOMMENDED | 推奨される (推奨される慣行) |
| MAY | してもよい (任意) |
1.2.2. Syntactic Notation (構文表記法)
本仕様は、RFC 5234 に記述されている拡張バッカス・ナウア記法 (ABNF, Augmented Backus-Naur Form) 表記法を使用します。文字は、10進値 (例: %d65 は大文字の A、%d97 は小文字の a) または引用符で囲まれた大文字小文字を区別しないリテラル値 (例: "A" は大文字または小文字の A を表す) のいずれかで指定されます。
ABNF の基礎:
- リテラル:
"From:"- 大文字小文字を区別しない - 10進値:
%d65- ASCII コード 65 (文字 A) - 範囲:
%d48-57- 数字 0-9 - 繰り返し:
*(0回以上)、1*(1回以上)、2*4(2〜4回) - オプション:
[OPTIONAL]- 角括弧内の要素はオプション - グループ化:
()- 丸括弧で要素をグループ化 - 代替:
/- いずれかを選択
1.2.3. Structure of This Document (本文書の構造)
本文書はいくつかのセクションに分かれています。
本セクション (セクション 1) は、文書への簡単な紹介です。
セクション 2 は、メッセージとその構成部分の一般的な説明を示します。これは、本文書の後半部分で使用される一般原則のいくつかを読者が理解するのに役立つ概要です。このセクションの例は、メッセージのいかなる部分の正式な仕様としても解釈してはなりません (MUST NOT)。
セクション 3 は、メッセージの各部分の構造 (構文、Syntax) の正式な ABNF 規則を指定し、それらの部分間の関係とメッセージのコンテキストにおけるそれらの意味 (セマンティクス、Semantics) を記述します。メッセージの各部分の構造の実際の規則 (構文) と、それらに関する説明と説明的な注記 (セマンティクス) をリストします。これには、特定の構造を持つメッセージサブパートの構文とセマンティクスの分析の両方が含まれます。セクション 3 の構文は、メッセージをどのように作成しなければならないか (MUST) を表します。構文のオプションが他のオプションよりも優先して使用されるべきか (SHOULD) どうかを示す注記もセクション 3 にあります。
セクション 2 とセクション 3 の両方が、本仕様に従って生成することが合法なメッセージを記述しています。
セクション 4 は「廃止された」(Obsolete) 構文を規定します。これらの廃止された構文要素は、セクション 3 で参照されています。廃止された構文の規則は、本仕様の以前のバージョンに現れた要素、またはインターネット上で広く使用されている要素ですが、メッセージを生成する際にはもはや使用されません。その結果、準拠するメッセージパーサーはこれらの要素を解釈しなければなりません (MUST)。ただし、この構文の項目は相互運用不可能であるか、メッセージ受信者に重大な問題を引き起こすと判断されているため、準拠するメッセージ作成者はそれらを生成してはなりません (MUST NOT)。
セクション 5 は、本仕様を実装する際のセキュリティに関する考慮事項を詳述します。
付録 A は、さまざまなタイプのメッセージの例をリストします。これらの例は、インターネット上に表示されるメッセージのタイプを網羅するものではありませんが、特定の構文形式の広範な概要を提供します。
付録 B は、本仕様と以前のインターネットメッセージ仕様との違いをリストします。
付録 C には謝辞が含まれています。
主要概念の要約
メッセージ構造
+-------------------------+
| ヘッダーセクション | ← 本仕様で定義
| - From: alice@... |
| - To: bob@... |
| - Subject: Hello |
| - Date: ... |
+-------------------------+
| 空行 (CRLF) | ← 必須の区切り文字
+-------------------------+
| 本文セクション | ← 本仕様 (プレーンテキスト)
| Hello World! | MIME が拡張 (マルチメディア)
+-------------------------+
仕様の範囲
| 内容 | 本仕様 | 他の仕様 |
|---|---|---|
| メッセージコンテンツ形式 | ✅ 定義 | - |
| メッセージ転送 (SMTP) | ❌ 対象外 | RFC 5321 |
| エンベロープ情報 | ❌ 対象外 | RFC 5321 |
| マルチメディアコンテンツ | ❌ 対象外 | RFC 2045-2049 (MIME) |
| ローカルストレージ形式 | ❌ 対象外 | システム固有 |
| 文字エンコーディング | ❌ 未指定 | 転送層 |
関連 RFC との関係
RFC 5322 (本 RFC)
↓ 定義
メッセージ形式 (IMF)
↓ 拡張
MIME シリーズ (RFC 2045-2049)
↓ 転送
SMTP (RFC 5321)
文書読解ガイド
- クイック理解: セクション 1-2 を読む (概要)
- 実装仕様: セクション 3 を学習 (メッセージ生成)
- レガシー互換性: セクション 4 を参照 (メッセージ解析)
- セキュリティ: セクション 5 を確認
- 実例: 付録 A を参照