1. 序論
1.1. 適用範囲
本文書は、インターネットメッセージ形式 (IMF, Internet Message Format) を規定します。これは、「電子メール」メッセージの枠組みの中で、コンピュータユーザー間で送信されるテキストメッセージのための構文です。本仕様は [RFC2822] の更新であり、[RFC2822] 自体は [RFC0822] に取って代わったもので、現在の慣行を反映するようにそれを更新し、[RFC1123] などの他の RFC で規定された漸進的な変更を組み込んでいます。
本文書は、テキストメッセージのための構文のみを規定します。特に、電子メールメッセージにおける画像、音声、その他の種類の構造化データの伝送については何も規定していません。そのようなデータを電子メールを通じて伝送するための機構を記述した拡張がいくつか公開されています。たとえば MIME 文書シリーズ ([RFC2045]、[RFC2046]、[RFC2049]) は、ここで規定する構文を拡張するか、あるいはそのようなメッセージをこの構文に適合するように構造化することによって、そのようなデータの伝送機構を記述しています。それらの機構は本仕様の適用範囲外です。
電子メールの文脈では、メッセージはエンベロープ (envelope) と内容 (contents) を持つものとして見なされます。エンベロープには、伝送と配送を達成するために必要なあらゆる情報が含まれます (エンベロープの議論については [RFC5321] を参照してください)。内容は、受信者へ配送される対象を構成します。本仕様は、メッセージの内容の形式とその一部の意味論にのみ適用されます。エンベロープ内の情報の仕様は含まれていません。
ただし、一部のメッセージシステムは、エンベロープを作成するために内容からの情報を使用することがあります。本仕様は、プログラムによるそのような情報の取得を容易にすることを意図しています。
本仕様は、システム間で受け渡されるメッセージの内容形式とは何かを定義することを意図しています。一部のメッセージシステムはこの形式でメッセージをローカルに保存し (これにより形式間の変換の必要がなくなります)、他のシステムは本仕様で規定されたものとは異なる形式を使用しますが、ローカルでの保存は本仕様の適用範囲外です。
注意: 本仕様は、サイトが使用する内部形式、サイトがサポートすることが期待される特定のメッセージシステム機能、またはメッセージを作成もしくは読み取るユーザーインターフェースプログラムの特性のいずれをも規定することを意図していません。さらに、本文書は、伝送および保存のいずれのための文字の符号化も規定していません。すなわち、使用されるビット数や、それらのビットが具体的にどのようにして回線上を転送されたりディスク上に保存されたりするかは規定していません。
1.2. 表記規則
1.2.1. 要件表記法
本文書では、大文字で現れる用語がときどき使用されます。"MUST"、"SHOULD"、"RECOMMENDED"、"MUST NOT"、"SHOULD NOT"、および "MAY" という用語が大文字で現れる場合、それらは本仕様の特定の要件を示すために使用されています。これらの用語の意味の議論は [RFC2119] にあります。
1.2.2. 構文表記法
本仕様は、メッセージの構文を形式的に定義するために、拡張バッカス・ナウア記法 (ABNF, Augmented Backus-Naur Form) [RFC5234] 表記法を使用します。文字は、10 進値 (たとえば、大文字の A に対しては値 %d65、小文字の a に対しては %d97) によって指定されるか、引用符で囲まれた大文字小文字を区別しないリテラル値 (たとえば、大文字または小文字の A に対して "A") によって指定されます。
1.2.3. 本文書の構造
本文書はいくつかの節に分かれています。
本節 (セクション 1) は、本文書への短い序論です。
セクション 2 は、メッセージとその構成部分の一般的な説明を示します。これは、本文書の後半で使用される一般原則のいくつかを読者が理解するのに役立つ概要です。本節のいかなる例も、メッセージのいかなる部分の形式的な構文の仕様として受け取ってはなりません (MUST NOT)。
セクション 3 は、メッセージの各部分の構造 (構文) についての形式的な ABNF 規則を規定し、それらの部分と、メッセージの文脈におけるそれらの部分の意味 (意味論) との関係を記述します。すなわち、メッセージの各部分の構造 (構文) に関する実際の規則を示すとともに、それらの部分の記述と、それらを解釈するための指示 (意味論) を述べます。これには、特定の構造を持つメッセージの下位部分の構文と意味論の分析が含まれます。セクション 3 に含まれる構文は、メッセージが作成されなければならない (MUST) とおりの姿を表します。また、セクション 3 には、構文で規定された選択肢のいずれかが他のものよりも使用されるべき (SHOULD) かどうかを示す注記もあります。
セクション 2 とセクション 3 はともに、本仕様の目的において生成することが合法なメッセージを記述しています。
本文書のセクション 4 は「廃止された (obsolete)」構文を規定します。セクション 3 には、これらの廃止された構文要素への参照があります。廃止された構文の規則は、本仕様の以前の版に現れていた要素、または以前にインターネットメッセージで広く使用されていた要素です。そのため、これらの要素は、本仕様に適合するためには、メッセージのパーサーによって解釈されなければなりません (MUST)。しかし、この構文の項目は相互運用が不可能であると判断されているか、メッセージの受信者にとって重大な問題を引き起こすと判断されているため、適合するメッセージの作成者はそれらを生成してはなりません (MUST NOT)。
セクション 5 は、本仕様を実装する際に考慮すべきセキュリティに関する事項を詳述します。
付録 A は、さまざまな種類のメッセージの例を列挙します。これらの例は、インターネット上に現れるメッセージの種類を網羅するものではありませんが、特定の構文形式の広い概要を与えます。
付録 B は、本仕様と、以前のインターネットメッセージの仕様との間の差異を列挙します。
付録 C には謝辞が含まれています。