1. Introduction (简介)
1.1. Scope (范围)
本文档定义了互联网消息格式 (IMF, Internet Message Format),这是一种用于在计算机用户之间发送文本消息的语法,属于"电子邮件"消息框架的一部分。本规范是对 [RFC2822] 的更新,而RFC2822本身取代了 [RFC0822],更新了该标准以反映当前实践,并纳入了其他RFC (如 [RFC1123]) 中指定的增量变更。
本文档仅为文本消息指定语法。特别地,它不对电子邮件消息中图像、音频或其他类型的结构化数据的传输做出规定。已发布了若干扩展,例如MIME文档系列 ([RFC2045], [RFC2046], [RFC2049]),它们描述了通过电子邮件传输此类数据的机制,可以通过扩展此处提供的语法或将此类消息构造为符合本语法来实现。这些机制超出了本规范的范围。
在电子邮件的上下文中,消息被视为具有信封 (Envelope) 和内容 (Contents)。信封包含完成传输和投递所需的任何信息 (参见 [RFC5321] 对信封的讨论)。内容包括要投递给收件人的对象。本规范仅适用于消息内容的格式和部分语义。它不包含对信封中信息的规范。
但是,某些消息系统可能会使用内容中的信息来创建信封。本规范旨在促进程序获取此类信息。
本规范旨在作为在系统之间传递的消息内容格式的定义。虽然某些消息系统在本地以这种格式存储消息 (这消除了格式之间转换的需要),而其他系统使用与本规范中指定的格式不同的格式,但本地存储超出了本规范的范围。
注意: 本规范无意规定站点使用的内部格式、它们预期支持的特定消息系统功能或创建或阅读消息的用户界面程序的任何特性。此外,本文档不指定用于传输或存储的字符编码; 也就是说,它不指定使用的位数或如何在线路上传输或在磁盘上存储这些位。
1.2. Notational Conventions (符号约定)
1.2.1. Requirements Notation (需求表示法)
本文档偶尔使用以大写字母出现的术语。当术语"MUST"、"SHOULD"、"RECOMMENDED"、"MUST NOT"、"SHOULD NOT"和"MAY"以大写形式出现时,它们用于指示本规范的特定要求。这些术语的含义讨论见 [RFC2119]。
关键词对照表:
| 英文 | 中文翻译 | 含义 |
|---|---|---|
| MUST | 必须 | 绝对要求 |
| MUST NOT | 禁止 | 绝对禁止 |
| SHOULD | 应该 | 强烈建议但非必需 |
| SHOULD NOT | 不应该 | 强烈不建议但非禁止 |
| RECOMMENDED | 推荐 | 建议采用 |
| MAY | 可以 | 允许但可选 |
1.2.2. Syntactic Notation (语法表示法)
本规范使用扩充巴科斯-瑙尔范式 (ABNF, Augmented Backus-Naur Form) [RFC5234] 表示法来正式定义消息的语法。字符将通过十进制值 (例如,%d65表示大写A,%d97表示小写a) 或用引号括起来的不区分大小写的字面值 (例如,"A"表示大写或小写A) 来指定。
ABNF基础:
- 字面值:
"From:"- 不区分大小写 - 十进制值:
%d65- ASCII码65 (字符A) - 范围:
%d48-57- 数字0-9 - 重复:
*(零次或多次),1*(一次或多次),2*4(2到4次) - 可选:
[OPTIONAL]- 方括号内的元素可选 - 分组:
()- 圆括号分组元素 - 备选项:
/- 选择其一
1.2.3. Structure of This Document (本文档结构)
本文档分为若干部分。
本节 (第1节) 是对文档的简短介绍。
第2节概述了消息及其组成部分的一般描述。这是一个概述,帮助读者理解本文档后续部分中使用的一些一般原则。本节中的任何示例都禁止 (MUST NOT) 被视为消息任何部分的正式语法规范。
第3节为消息每个部分的结构指定了正式的ABNF规则 (语法, Syntax),并描述了这些部分之间的关系及其在消息上下文中的含义 (语义, Semantics)。也就是说,它列出了消息每个部分结构的实际规则 (语法),以及对这些部分的描述和解释说明 (语义)。这包括对具有特定结构的消息子部分的语法和语义分析。第3节中包含的语法表示消息必须 (MUST) 如何创建。第3节中还有注释,指出语法中的某些选项是否应该 (SHOULD) 优先于其他选项使用。
第2节和第3节都描述了根据本规范合法生成的消息。
第4节规定了"废弃" (Obsolete) 语法。第3节中引用了这些废弃的语法元素。废弃语法的规则是出现在本规范早期版本中或以前在互联网消息中广泛使用的元素。因此,为了符合本规范,消息解析器必须 (MUST) 解释这些元素。但是,由于此语法中的项目已被确定为不可互操作或对消息接收者造成重大问题,因此符合规范的消息创建者禁止 (MUST NOT) 生成它们。
第5节详细说明了实现本规范时要考虑的安全事项。
附录A列出了不同类型消息的示例。这些示例并未穷尽互联网上出现的消息类型,但提供了某些语法形式的广泛概述。
附录B列出了本规范与早期互联网消息规范之间的差异。
附录C包含致谢。
关键概念总结
消息结构
+-------------------------+
| 头部区域 (Header) | ← 本规范定义
| - From: alice@... |
| - To: bob@... |
| - Subject: Hello |
| - Date: ... |
+-------------------------+
| 空行 (CRLF) | ← 必需的分隔符
+-------------------------+
| 消息体 (Body) | ← 本规范定义 (纯文本)
| 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