1. 引言

1.1. 范围

本文档规定了 Internet Message Format (IMF, 互联网消息格式), 即在"电子邮件"消息框架内, 计算机用户之间发送的文本消息的一种语法. 本规范是对 [RFC2822] 的更新, 而 [RFC2822] 本身取代了 [RFC0822], 并对其进行了更新以反映当前实践, 同时纳入了其他 RFC (如 [RFC1123]) 中规定的增量变更.

本文档仅规定文本消息的语法. 特别是, 它不规定如何在电子邮件消息中传输图像、音频或其他类型的结构化数据. 已发布的若干扩展, 例如 MIME 文档系列 ([RFC2045], [RFC2046], [RFC2049]), 描述了通过电子邮件传输此类数据的机制, 这些机制要么扩展了此处提供的语法, 要么把此类消息组织成符合本语法的形式. 这些机制不在本规范的范围之内.

在电子邮件的语境中, 消息被视为由信封 (envelope) 和内容 (contents) 组成. 信封包含完成传输和投递所需的任何信息. (关于信封的讨论见 [RFC5321].) 内容则构成要投递给收件人的对象. 本规范仅适用于消息内容的格式以及其中一部分语义. 它不规定信封中的任何信息.

不过, 某些消息系统可能会使用内容中的信息来创建信封. 本规范旨在便于程序获取此类信息.

本规范旨在定义系统之间应当传递何种消息内容格式. 尽管有些消息系统以此格式在本地存储消息 (从而无需在格式之间转换), 其他系统则使用与本规范所规定格式不同的格式, 但本地存储不在本规范的范围之内.

注意: 本规范无意规定各站点使用的内部格式、它们预期支持的具体消息系统功能, 或创建或读取消息的用户界面程序的任何特性. 此外, 本文档不规定用于传输或存储的字符编码; 也就是说, 它不规定使用的比特数, 也不规定这些比特如何经由线路传输或存储在磁盘上.

1.2. 记号约定

1.2.1. 需求记号

本文档偶尔使用以大写字母出现的术语. 当术语 "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT" 和 "MAY" 以大写形式出现时, 它们用于表示本规范的特定要求. 这些术语含义的讨论见 [RFC2119].

1.2.2. 语法记号

本规范使用 Augmented Backus-Naur Form (ABNF, 扩充巴科斯-瑙尔范式) [RFC5234] 记号来给出消息语法的形式化定义. 字符要么通过十进制值指定 (例如, 值 %d65 表示大写 A, %d97 表示小写 a), 要么通过用引号括起的不区分大小写的字面值指定 (例如, "A" 表示大写或小写的 A).

1.2.3. 本文档的结构

本文档分为若干节.

本节 (第 1 节) 是对本文档的简要介绍.

第 2 节给出消息及其组成部分的一般性描述. 这是一个概览, 用于帮助读者理解本文档后续部分所采用的一些一般原则. 本节中的任何示例都不得被视为对消息任何部分形式语法的规定.

第 3 节规定消息各部分结构 (语法) 的形式化 ABNF 规则, 并描述这些部分之间的关系及其在消息语境中的含义 (语义). 也就是说, 它既列出消息各部分结构的实际规则 (语法), 也给出对各部分的说明及其解释方式 (语义). 这包括对具有特定结构的消息子部分进行语法和语义分析. 第 3 节中包含的语法表示消息必须如何创建. 第 3 节中还包含一些注记, 用于指明语法中规定的某些选项是否应当优先于其他选项使用.

第 2 节和第 3 节都描述为达成本规范目的而可以合法生成的消息.

本文档第 4 节规定一种 "obsolete" (过时) 语法. 第 3 节中引用了这些过时语法元素. 过时语法的规则是那些在早期版本的本规范中出现过, 或者此前在互联网消息中被广泛使用的元素. 因此, 为符合本规范, 消息解析器必须解释这些元素. 但是, 由于此语法中的项目已被认定为不可互操作, 或者会给消息接收者造成重大问题, 符合规范的消息创建者不得生成它们.

第 5 节详述实现本规范时需要考虑的安全事项.

附录 A 列出不同类型消息的示例. 这些示例并未穷尽互联网上出现的消息类型, 但对若干语法形式给出了广泛的概览.

附录 B 列出本规范与早期互联网消息规范之间的差异.

附录 C 包含致谢.