非官方中文译本声明：本页为 IETF RFC 5322《Internet Message Format（Internet 报文格式）》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc5322。
RFC 5322：Internet 报文格式
目录
- 封面
- 本备忘录的状态
- 摘要
- 1. 引言
- 2. 报文的词法分析
- 3. 语法
- 4. 废弃语法
- 5. 安全考量
- 6. IANA 考量
- 附录 A. 示例报文
- 附录 B. 与早期规范的差异
- 附录 C. 致谢
- 7. 参考文献
封面
本备忘录的状态
本文档规定了面向 Internet 社区的 Internet 标准跟踪协议，并征求改进意见与建议。关于本协议的标准化状态与现状，请参阅"Internet 官方协议标准"（STD 1）的当前版本。本备忘录的分发不受限制。
摘要
本文档规定了 Internet 报文格式（IMF，Internet Message Format），即在"电子邮件"消息框架内、计算机用户之间发送的文本消息的语法。本规范是对请求评论文档（RFC）2822 的修订，而 2822 本身又取代了 RFC 822《ARPA Internet 文本消息格式标准》，将其更新以反映当前实践，并纳入在其他 RFC 中规定的增量性变更。
1. 引言
1.1. 范围
本文档规定了 Internet 报文格式（IMF），即在"电子邮件"消息框架内、计算机用户之间发送的文本消息的语法。本规范是对 [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）[RFC5234] 记法来对消息语法的形式化定义进行描述。字符将通过十进制值（例如，大写 A 为 %d65、小写 A 为 %d97）或括在引号中的、不区分大小写的字面量值（例如，"A" 表示大写或小写 A）来指定。
1.2.3. 本备忘录的结构
本文档分为若干节。
本节即第 1 节，是对文档的简短介绍。
第 2 节给出了消息及其组成部分的总体描述。这是一份概述，旨在帮助读者理解本文档后续部分所采用的一些通用原则。本节中的任何示例都不得被视为对消息任何部分形式化语法的规范。
第 3 节规定了消息每个部分结构的形式化 ABNF 规则（语法），并描述了这些部分之间的关系，以及它们在消息语境下的含义（语义）。也就是说，它列出了消息每个部分结构（语法）的实际规则，以及对各部分的描述和解释指引（语义）。这包括对消息中具有特定结构的子部分之语法与语义的分析。第 3 节中的语法表示消息在创建时"必须"采用的形态。第 3 节中也有说明，指出语法中规定的任何选项是否"应该"优先于其他选项使用。
第 2 节和第 3 节均描述了为本规范目的而合法可生成的消息。
本文档第 4 节规定了一种"废弃（obsolete）"语法。第 3 节中有对这些废弃语法元素的引用。废弃语法的规则是那些出现在本规范早期版本中、或先前在 Internet 消息中被广泛使用过的元素。因此，为符合本规范，消息的解析器"必须"解释这些元素。然而，由于该语法中的各项已被确定为不可互操作、或会给消息收件人带来严重问题，符合规范的消息创建者"不得"生成它们。
第 5 节详述了实现本规范时应考虑的安全事项。
附录 A 列出了不同类型消息的示例。这些示例并非 Internet 上出现的消息类型的穷举，但给出了某些语法形态的概览。
附录 B 列出了本规范与早期 Internet 消息规范之间的差异。
附录 C 包含致谢。
2. 报文的词法分析
2.1. 概述
在最基础的层面上，一条消息是一系列字符。符合本规范的消息由取值范围在 1 至 127 之间、并被解释为 US-ASCII [ANSI.X3-4.1986] 字符的字符组成。为简洁起见，本文档有时将该范围内的字符简称为"US-ASCII 字符"。
注意：本文档规定消息由 US-ASCII 范围内 1 至 127 的字符组成。另有其他文档，特别是 MIME 文档系列（[RFC2045]、[RFC2046]、[RFC2047]、[RFC2049]、[RFC4288]、[RFC4289]），对本规范进行了扩展以允许该范围之外的值。对这些机制的讨论不在本规范的范围内。
消息被划分为若干字符行。一行是由两个字符——回车符（carriage-return）与换行符（line-feed）——所界定的字符序列；即回车（CR）字符（ASCII 值 13）紧跟换行（LF）字符（ASCII 值 10）。（回车/换行对通常在本文档中写作"CRLF"。）
一条消息由头字段（统称为消息的"头节（header section）"）组成，其后可选地跟有一个主体（body）。头节是一系列具有本规范所定义特殊语法的字符行。主体则只是跟在头节之后的一串字符，并借由一个空行（即，CRLF 之前没有任何内容的行）与头节分隔。
注意：惯常用语以及本规范的早期版本使用"header（报头）"这一术语来指代整个头节，或指代单个头字段。为避免歧义，本文档不孤立地使用"header"或"headers"这些术语，而是始终用"header field（头字段）"指代单个字段，用"header section（头节）"指代整个集合。
2.1.1. 行长度限制
本规范对一行中的字符数量施加了两个限制。每个字符行"必须"不超过 998 个字符，且"应该"不超过 78 个字符（CRLF 不计入）。
998 个字符的限制源于许多发送、接收或存储 IMF 消息的实现，它们根本无法处理一行中超过 998 个字符的情况。出于健壮性考虑，接收方实现最好能处理一行中任意数量的字符。然而，有如此多的实现（为符合 [RFC5321] 的传输要求）不接受每行包含超过 1000 个字符（含 CR 与 LF）的消息，因此实现不去创建此类消息是很重要的。
更保守的 78 字符建议，是为了适应许多显示这些消息的用户界面实现，它们可能会截断或以灾难性的方式折行显示每行超过 78 个字符的内容——尽管此类实现违背了本规范（以及 [RFC5321]，如果它们确实导致信息丢失的话）的意图。再次强调，尽管该限制施加于消息之上，但出于健壮性考虑，显示消息的实现有责任处理一行中任意数量的字符（至少肯定要达到 998 字符的限制）。
2.2. 头字段
头字段是一些以字段名开始、后跟冒号（":"）、再跟字段体并以 CRLF 终止的行。字段名"必须"由可打印的 US-ASCII 字符（即，值介于 33 与 126 之间，含端点的字符）组成，冒号除外。字段体可由可打印的 US-ASCII 字符以及空格（SP，ASCII 值 32）和水平制表符（HTAB，ASCII 值 9）字符（二者合称空白字符，WSP）组成。字段体"不得"包含 CR 和 LF，除非在如第 2.2.3 节所述的"折叠（folding）"与"展开（unfolding）"中使用。所有字段体都必须符合本规范第 3 节和第 4 节中描述的语法。
2.2.1. 非结构化头字段体
本规范中的某些字段体被简单地定义为"非结构化"（在第 3.2.5 节中定义为任意可打印 US-ASCII 字符加上空白字符），没有进一步的限制。这些被称为非结构化字段体。在语义上，非结构化字段体就是作为一个单行字符来处理，无需进一步处理（第 2.2.3 节所述的"折叠"与"展开"除外）。
2.2.2. 结构化头字段体
本规范中的某些字段体具有比上述非结构化字段体更严格的语法。这些被称为"结构化"字段体。结构化字段体是本规范第 3 节和第 4 节所描述的特定词法记号的序列。这些记号中有许多（依其语法）允许引入或以注释（见第 3.2.2 节）以及空白字符结尾，而这些空白字符要遵行第 2.2.3 节所述的"折叠"与"展开"。结构化字段体的语义分析随其语法一并给出。
2.2.3. 长头字段
每个头字段在逻辑上是由字段名、冒号和字段体组成的一行字符。然而，为了方便，并应对每行 998/78 字符的限制，头字段的字段体部分可以被拆分成多行的表示形式；这称为"折叠（folding）"。一般规则是：凡本规范允许折叠空白（而不仅是 WSP 字符）之处，都可以在任何 WSP 之前插入一个 CRLF。
例如，头字段：
Subject: This is a test
可以表示为：
Subject: This is a test
注意：尽管结构化字段体的定义使得折叠可以发生在许多词法记号之间（甚至在某些词法记号内部），但折叠"应该"限于将 CRLF 置于较高层级的语法断点处。例如，如果一个字段体被定义为逗号分隔的值，则推荐折叠发生在分隔结构化条目的逗号之后，优先于字段本可折叠的其他位置，即便其他位置也是允许的。
将头字段从其折叠的多行表示形式转换为单行表示形式的过程称为"展开（unfolding）"。展开只需简单地移除任何紧跟 WSP 的 CRLF 即可完成。每个头字段在其展开形式下，才能用于进一步的语法与语义分析。展开后的头字段没有长度限制，因而可能是任意长的。
2.3. 主体
消息的主体就是一行行 US-ASCII 字符。对主体仅有的两项限制如下：
- CR 和 LF 只能作为 CRLF 成对出现；它们"不得"在主体中独立出现。
- 主体中的字符行"必须"限制为 998 个字符，且"应该"限制为 78 个字符（CRLF 不计入）。
注意：如前所述，另有其他文档，特别是 MIME 文档（[RFC2045]、[RFC2046]、[RFC2049]、[RFC4288]、[RFC4289]），对本规范进行了扩展（并施加限制），以允许不同类型的消息主体。同样，这些机制超出本文档的范围。
3. 语法
3.1. 引言
本节给出的语法定义了 Internet 消息的合法语法。符合本规范的消息"必须"符合本节中的语法。如果本节中的某些选项指示某个选项"应该"被生成，则会在散文描述中或在语法旁的注释中予以说明。
对于每个已定义的表达式，先给出对语法与用途的简短描述，然后给出 ABNF 形式的语法，最后给出语义分析。以下被使用但未另行说明的基本记号取自 [RFC5234] 附录 B.1 的"核心规则"：CR、LF、CRLF、HTAB、SP、WSP、DQUOTE、DIGIT、ALPHA 和 VCHAR。
在某些定义中，会出现名称以"obs-"开头的非终结符。这些"obs-"元素引用第 4 节废弃语法中定义的记号。在所有情况下，出于生成合法 Internet 消息之目的，这些产生式应被忽略，且"不得"作为此类消息的一部分使用。然而，在解释消息时，这些记号"必须"作为合法语法的一部分被遵守。从这个意义上说，第 3 节定义了一个用于生成消息的文法（其中"obs-"元素应被忽略），而第 4 节则为消息的解释增添了文法。
3.2. 词法记号
以下规则用于定义一个底层的词法分析器，它向更高层的解析器提供记号。本节定义结构化头字段体中使用的记号。
注意：本规范的读者需要特别留意这些词法记号在文档后续低层与高层语法中的用法。特别是，第 3.2.2 节定义的空白记号和注释记号被用于此处定义的低层记号，而这些低层记号又依次用作后续定义的高层记号的组成部分。因此，即便某些高层记号中并未显式出现空白与注释，它们仍可能出现在这些高层记号之中。
3.2.1. 被引用的字符
某些字符被保留用于特殊解释，例如用作界定词法记号的定界符。为允许将这些字符用作未经解释的数据，提供了一种引号机制。
quoted-pair = ("\" (VCHAR / WSP)) / obs-qp
在任何 quoted-pair 出现之处，它应被解释为该字符本身。也就是说，作为 quoted-pair 一部分出现的"\"字符在语义上是"不可见"的。
注意："\"字符可能出现在消息中而并非 quoted-pair 的一部分。一个不属于 quoted-pair 的"\"字符在语义上并非不可见。本规范中当前出现 quoted-pair 的唯一位置是 ccontent、qcontent，以及第 4 节中的 obs-dtext。
3.2.2. 折叠空白与注释
空白字符，包括折叠中使用的空白（在第 2.2.3 节中描述），可以出现在头字段体的许多元素之间。此外，被视为注释的字符串可以作为括在括号中的字符，被包含在结构化字段体中。以下定义了折叠空白（FWS）与注释结构。
只要括在括号内的字符串不出现在第 3.2.4 节定义的"quoted-string"之内，它们就被视为注释。注释可以嵌套。
本规范中有若干位置可以自由插入注释与 FWS。为容纳该语法，额外定义了一个"CFWS"记号，表示可出现注释和/或 FWS 的位置。然而，在本规范中 CFWS 出现之处，"不得"以使得某个折叠头字段的某一行完全由 WSP 字符、而别无他物的方式插入它。
FWS = ([*WSP CRLF] 1*WSP) / obs-FWS
; Folding white space
ctext = %d33-39 / ; Printable US-ASCII
%d42-91 / ; characters not including
%d93-126 / ; "(", ")", or "\"
obs-ctext
ccontent = ctext / quoted-pair / comment
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = (1*([FWS] comment) [FWS]) / FWS
在本规范的任何位置，凡出现 FWS（折叠空白记号）之处，都指示了如第 2.2.3 节所讨论的、可能发生折叠的位置。凡消息中出现折叠之处（即，一个包含 CRLF 后跟任意 WSP 的头字段体），在依据本规范对该头字段进行任何进一步语义分析之前，要先执行展开（移除 CRLF）。也就是说，出现在 FWS 中的任何 CRLF 在语义上是"不可见"的。
注释通常用在结构化字段体中，以提供某些供人阅读的信息文本。由于注释允许包含 FWS，因此允许在注释内部折叠。另需注意，由于 quoted-pair 允许出现在注释中，所以只要括号和反斜杠字符以 quoted-pair 形式出现，它们就可以出现在注释中。在语义上，括住注释的括号并不是注释的一部分；注释是两个括号之间的内容。如前所述，任何 quoted-pair 中的"\"以及注释内出现的任何 FWS 中的 CRLF 在语义上是"不可见"的，因此也不是注释的一部分。
在结构化头字段中，出现在词法记号之间的 FWS、注释或 CFWS 的连续串，在语义上被解释为一个空格字符。
3.2.3. 原子
结构化头字段体中的若干产生式只是某些基本字符的串。此类产生式称为原子（atoms）。
某些结构化头字段体还允许在 atext 连续串中出现句点字符（"."，ASCII 值 46）。为此额外定义了一个"dot-atom"记号。
注意："specials"记号并未在本规范的其他任何地方出现。它仅仅是未出现在 atext 中的可见（即，非控制、非空白）字符。提供它只是因为它对使用词法分析工具分析消息的实现者有用。specials 中的每个字符都可用于指示词法分析中的一个分词点。
atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
atom = [CFWS] 1*atext [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS]
specials = "(" / ")" / ; Special characters that do
"<" / ">" / ; not appear in atext
"[" / "]" /
":" / ";" /
"@" / "\" /
"," / "." /
DQUOTE
atom 和 dot-atom 都被解释为一个单一单元，由组成它的字符串构成。在语义上，环绕其余字符的可选注释与 FWS 并非 atom 的一部分；atom 只是 atom 中 atext 字符的连续串，或 dot-atom 中 atext 与"."字符的连续串。
3.2.4. 引用字符串
包含 atom 所不允许字符的字符串，可以用引用字符串（quoted string）格式表示，其中字符被引号（DQUOTE，ASCII 值 34）字符包围。
qtext = %d33 / ; Printable US-ASCII
%d35-91 / ; characters not including
%d93-126 / ; "\" or the quote character
obs-qtext
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
引用字符串被视为一个单元。也就是说，quoted-string 在语义上与 atom 完全相同。由于 quoted-string 允许包含 FWS，因此允许折叠。另需注意，由于 quoted-pair 允许出现在 quoted-string 中，所以只要引号与反斜杠字符以 quoted-pair 形式出现，它们就可以出现在 quoted-string 中。
在语义上，引号字符之外的可选 CFWS 以及引号字符本身都不是 quoted-string 的一部分；quoted-string 是两个引号字符之间的内容。如前所述，任何 quoted-pair 中的"\"以及出现在 quoted-string 内任何 FWS/CFWS 中的 CRLF 在语义上是"不可见"的，因此也不是 quoted-string 的一部分。
3.2.5. 杂项记号
定义了三个额外的记号：word 与 phrase 用于 atom 和/或 quoted-string 的组合，unstructured 用于非结构化头字段以及结构化头字段内的某些位置。
word = atom / quoted-string phrase = 1*word / obs-phrase unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct
3.3. 日期与时间规范
日期与时间值出现在若干头字段中。本节规定了完整日期与时间规范的语法。尽管在日期-时间规范中允许折叠空白，但建议在每次出现 FWS 的位置（无论是否必需）都只使用单个空格；某些较旧的实现不能正确解释更长的折叠空白序列。
date-time = [ day-of-week "," ] date time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"
date = day month year
day = ([FWS] 1*2DIGIT FWS) / obs-day
month = "Jan" / "Feb" / "Mar" / "Apr" /
"May" / "Jun" / "Jul" / "Aug" /
"Sep" / "Oct" / "Nov" / "Dec"
year = (FWS 4*DIGIT FWS) / obs-year
time = time-of-day zone
time-of-day = hour ":" minute [ ":" second ]
hour = 2DIGIT / obs-hour
minute = 2DIGIT / obs-minute
second = 2DIGIT / obs-second
zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone
day 是月份中的数字日期。year 是 1900 年或之后的任意数字年份。
time-of-day 指明自所指日期午夜起经过的小时数、分钟数以及可选的秒数。
date 与 time-of-day"应该"表示本地时间。
zone 指明了 date 与 time-of-day 所表示的、相对于协调世界时（UTC，即"Greenwich Mean Time"，格林尼治标准时间）的偏移量。加号"+"或减号"-"表示该 time-of-day 是在通用时间之前（即，其东边）还是之后（即，其西边）。前两位数字表示与通用时间相差的小时数，后两位数字表示与通用时间相差的额外分钟数。（因此，+hhmm 表示 +(hh * 60 + mm) 分钟，-hhmm 表示 -(hh * 60 + mm) 分钟）。指示通用时间时，应使用"+0000"形式。"-0000"同样指示通用时间，但它用于表明：该时间是在一个可能处于通用时间之外的本地时区的系统上生成的，且该 date-time 不包含关于本地时区的任何信息。
date-time 规范在语义上"必须"有效。也就是说，day-of-week（如果包含）"必须"是 date 所隐含的那一天，数字 day-of-month"必须"介于 1 与所指月份（在所指年份中）所允许的天数之间，time-of-day"必须"在 00:00:00 至 23:59:60 的范围内（允许一个闰秒的秒数；见 [RFC1305]），且 zone 的后两位数字"必须"在 00 至 59 的范围内。
3.4. 地址规范
地址出现在若干消息头字段中，用以指明消息的发送者与接收者。一个地址可以是一个单独的邮箱（mailbox），也可以是一组邮箱。
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /
obs-angle-addr
group = display-name ":" [group-list] ";" [CFWS]
display-name = phrase
mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list
address-list = (address *("," address)) / obs-addr-list
group-list = mailbox-list / CFWS / obs-group-list
邮箱（mailbox）接收邮件。它是一个概念性实体，不一定与文件存储相关。例如，某些站点可能选择将邮件打印在打印机上，并将输出投递到收件人的办公桌。
通常，一个邮箱由两部分组成：（1）一个可选的显示名（display name），表明收件人（可以是个人或系统）的名称，它可以被邮件应用程序的用户看到；以及（2）一个括在尖括号（"<"和">"）中的 addr-spec 地址。还存在一种替代的简单邮箱形式，其中 addr-spec 地址单独出现，不带收件人姓名，也不带尖括号。Internet addr-spec 地址在第 3.4.1 节中描述。
注意：某些遗留实现使用了简单形式，其中 addr-spec 不带尖括号出现，但将收件人姓名作为 addr-spec 之后的注释括在括号内。由于注释中信息的含义未予规定，实现"应该"使用完整的 name-addr 形式的邮箱，而非遗留形式，以指定与邮箱关联的显示名。此外，由于某些遗留实现会解释注释，通常"不应"在地址字段中使用注释，以避免混淆此类实现。
当希望将若干邮箱作为一个单元处理时（即，在分发列表中），可以使用组（group）结构。组结构允许发送者指明一个具名的收件人组。做法是给出一个组的显示名，后跟冒号，再后跟任意数量（包括零个和一个）邮箱的逗号分隔列表，并以分号结束。由于邮箱列表可以为空，使用组结构也是一种简单的方式，用来向接收者传达消息是发送给一个或多个具名收件人集合的，而实际上并不提供那些收件人中任何个体的邮箱地址。
3.4.1. Addr-Spec 规范
addr-spec 是一个特定的 Internet 标识符，它包含一个本地解释的字符串，后跟 at 符号（"@"，ASCII 值 64），再后跟一个 Internet 域。本地解释的字符串要么是 quoted-string，要么是 dot-atom。如果该字符串可以表示为 dot-atom（即，它除了 atext 字符或被 atext 字符包围的"."之外不含其他字符），则"应该"使用 dot-atom 形式，且"不应"使用 quoted-string 形式。在 addr-spec 的"@"周围"不应"使用注释与折叠空白。
注意：此处给出了 addr-spec 域部分的宽松语法。然而，域部分包含由其他协议（例如 [RFC1034]、[RFC1035]、[RFC1123]、[RFC5321]）规定并使用的寻址信息。因此，实现有责任在所使用语境下符合地址的语法。
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
dtext = %d33-90 / ; Printable US-ASCII
%d94-126 / ; characters not including
obs-dtext ; "[", "]", or "\"
域部分标识邮件被投递到的那个点。在 dot-atom 形式中，它被解释为 [RFC1034]、[RFC1035] 和 [RFC1123] 所描述的 Internet 域名（主机名或邮件交换器名）。在 domain-literal 形式中，域被解释为该特定主机的字面 Internet 地址。在这两种情况下，如何使用寻址以及消息如何被传输到特定主机，都在独立文档（如 [RFC5321]）中涵盖。这些机制不在本文档的范围内。
local-part 部分是一个依赖于域的字符串。在地址中，它只是在特定主机上被简单地解释为某个特定邮箱的名称。
3.5. 整体报文语法
一条消息由头字段组成，其后可选地跟有一个消息主体。消息中的各行"必须"最多为 998 个字符（CRLF 不计入），但"建议"将各行限制为 78 个字符（CRLF 不计入）。（解释见第 2.1.1 节。）在消息主体中，尽管 text 规则中列出的所有字符都"可以"使用，但不鼓励使用 US-ASCII 控制字符（值 1 至 8、11、12，以及 14 至 31），因为接收方在显示时对其的解释不能保证。
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
%d12 /
%d14-127
头字段承载着大部分语义信息，并在第 3.6 节中定义。主体仅仅是出于本规范之目的未经解释的一行行文本。
3.6. 字段定义
消息的头字段在此定义。所有头字段具有相同的通用语法结构：一个字段名，后跟冒号，再跟字段体。每个头字段的具体语法在后续各节中定义。
注意：在后续各节的每个字段的 ABNF 语法中，每个字段名后都跟着必需的冒号。然而，为简洁起见，有时在语法的文字描述中不提及冒号。不过，冒号是必需的。
需要注意，头字段并不保证按特定顺序排列。它们可能以任意顺序出现，并且已知在通过 Internet 传输时偶尔会被重新排序。然而，就本规范而言，当消息被传输或转换时，头字段"不应"被重新排序。更重要的是，跟踪头字段与重发（resent）头字段"不得"被重新排序，且"应该"保持为前置（prepended）于消息的块。详见第 3.6.6 节与第 3.6.7 节。
唯一必需的头字段是发起日期字段（origination date field）与发起者地址字段（originator address field(s)）。所有其他头字段在语法上都是可选的。更多内容包含在下述定义之后的表中。
fields = *(trace
*optional-field /
*(resent-date /
resent-from /
resent-sender /
resent-to /
resent-cc /
resent-bcc /
resent-msg-id))
*(orig-date /
from /
sender /
reply-to /
to /
cc /
bcc /
message-id /
in-reply-to /
references /
subject /
comments /
keywords /
optional-field)
下表说明了每个字段在消息头节中出现次数的限制，以及使用这些字段的任何特殊限制。最小值或最大值列中带有星号（"*"）的值表示"注释"列中存在一项特殊限制。
| 字段 | 最小次数 | 最大次数 | 注释 |
|---|---|---|---|
| trace | 0 | 不限 | 块前置——见 3.6.7 |
| resent-date | 0* | 不限* | 每块一个，若其他 resent 字段出现则为必需——见 3.6.6 |
| resent-from | 0 | 不限* | 每块一个——见 3.6.6 |
| resent-sender | 0* | 不限* | 每块一个，必须与多地址 resent-from 一同出现——见 3.6.6 |
| resent-to | 0 | 不限* | 每块一个——见 3.6.6 |
| resent-cc | 0 | 不限* | 每块一个——见 3.6.6 |
| resent-bcc | 0 | 不限* | 每块一个——见 3.6.6 |
| resent-msg-id | 0 | 不限* | 每块一个——见 3.6.6 |
| orig-date | 1 | 1 | |
| from | 1 | 1 | 见 sender 与 3.6.2 |
| sender | 0* | 1 | 必须与多地址 from 一同出现——见 3.6.2 |
| reply-to | 0 | 1 | |
| to | 0 | 1 | |
| cc | 0 | 1 | |
| bcc | 0 | 1 | |
| message-id | 0* | 1 | "应该"出现——见 3.6.4 |
| in-reply-to | 0* | 1 | 在某些回复中"应该"出现——见 3.6.4 |
| references | 0* | 1 | 在某些回复中"应该"出现——见 3.6.4 |
| subject | 0 | 1 | |
| comments | 0 | 不限 | |
| keywords | 0 | 不限 | |
| optional-field | 0 | 不限 |
每个字段的确切解释在后续各节中描述。
3.6.1. 发起日期字段
发起日期字段由字段名"Date"后跟一个 date-time 规范组成。
orig-date = "Date:" date-time CRLF
发起日期指明了消息的创建者表明消息已完备、准备进入邮件投递系统的日期与时间。例如，这可能是用户在应用程序中按下"发送"或"提交"按钮的时刻。无论如何，它都不是为了传达消息实际被传输的时间，而是消息的人类或其他创建者将消息定稿、准备传输的时间。（例如，一个未连接网络的便携计算机用户可能将一条消息排队等待投递。发起日期意在包含用户将消息排队的时间，而不是用户连接到网络发送消息的时间。）
3.6.2. 发起者字段
消息的发起者字段由 from 字段、sender 字段（在适用时）以及可选的 reply-to 字段组成。from 字段由字段名"From"和一个或多个邮箱规范组成的逗号分隔列表构成。如果 from 字段在 mailbox-list 中包含多于一个邮箱规范，则包含字段名"Sender"和单个邮箱规范的 sender 字段"必须"出现在消息中。无论哪种情况，都可以包含一个可选的 reply-to 字段，它包含字段名"Reply-To"和一个或多个地址的逗号分隔列表。
from = "From:" mailbox-list CRLF sender = "Sender:" mailbox CRLF reply-to = "Reply-To:" address-list CRLF
发起者字段指明消息来源的邮箱。字段"From:"指定消息的作者（author(s)），即负责撰写消息的个人或系统的邮箱。字段"Sender:"指定负责消息实际传输的代理（agent）的邮箱。例如，如果一位秘书要替另一人发送消息，则秘书的邮箱会出现在"Sender:"字段中，而实际作者的邮箱会出现在"From:"字段中。如果消息的发起者可以用单个邮箱表示，且作者与传输者相同，则"不应"使用"Sender:"字段。否则，两个字段"都应该"出现。
注意：传输者信息总是存在的。缺少"Sender:"字段有时被错误地理解为意味着负责消息传输的代理没有被指定。这种缺失仅仅意味着传输者与作者相同，因此没有冗余地放入"Sender:"字段。
发起者字段还提供了回复消息时所需的信息。当存在"Reply-To:"字段时，它指明了作者建议回复所发往的地址。在缺少"Reply-To:"字段时，除非撰写回复者另有指定，否则回复默认"应该"发往"From:"字段中指定的邮箱。
在任何情况下，"From:"字段"不应"包含任何不属于消息作者的邮箱。另见第 3.6.3 节，了解关于形成回复目标地址的更多信息。
3.6.3. 目标地址字段
消息的目标字段由三个可能的字段组成，每个形式相同：字段名（"To"、"Cc"或"Bcc"之一），后跟一个或多个地址（mailbox 或 group 语法）的逗号分隔列表。
to = "To:" address-list CRLF cc = "Cc:" address-list CRLF bcc = "Bcc:" [address-list / CFWS] CRLF
目标字段指定消息的接收者。每个目标字段可以有一个或多个地址，这些地址指明了消息的预期接收者。三个字段之间唯一的区别在于各自的使用方式。
字段"To:"包含消息的主要接收者（primary recipient(s)）的地址。
字段"Cc:"（其中"Cc"意为"Carbon Copy"，即打字机上用复写纸制作副本之意）包含其他也将收到消息的人的地址，尽管消息内容可能不是针对他们。
字段"Bcc:"（其中"Bcc"意为"Blind Carbon Copy"，即盲复写副本）包含消息接收者的地址，这些地址不向消息的其他接收者透露。使用"Bcc:"字段有三种方式。第一种情况下，当准备发送一条含"Bcc:"字段的消息时，"Bcc:"行被移除，尽管所有接收者（包括那些在"Bcc:"字段中指定的）都被发送一份消息副本。第二种情况下，在"To:"和"Cc:"行中的接收者各自收到一份移除了上述"Bcc:"行的消息副本，而"Bcc:"行上的接收者得到一份包含"Bcc:"行的单独消息副本。（当"Bcc:"字段中有多个接收者地址时，某些实现实际上向每个接收者发送一份仅含该特定接收者地址的单独消息副本。）最后，由于"Bcc:"字段可以不含任何地址，因此可以发送一个不含任何地址的"Bcc:"字段，向接收者表明盲副本已发送给某人。使用"Bcc:"字段应采用哪种方法取决于实现，但关于每种方法的讨论，请参阅本文档的"安全考量"一节。
当一条消息是对另一条消息的回复时，原消息作者（"From:"字段中的邮箱）的邮箱或"Reply-To:"字段（若存在）中指定的邮箱"可以"出现在回复的"To:"字段中，因为这些通常就是回复的主要接收者。如果对一封带有目标字段的消息发送回复，通常除了作者之外，还希望将回复副本发送给消息的所有接收者。当形成此类回复时，原消息"To:"和"Cc:"字段中的地址"可以"出现在回复的"Cc:"字段中，因为这些通常是回复的次要接收者。如果原消息中存在"Bcc:"字段，该字段中的地址"可以"出现在回复的"Bcc:"字段中，但它们"不应"出现在"To:"或"Cc:"字段中。
注意：某些邮件应用程序具有自动回复命令，会将原消息的目标地址包含进回复的目标地址中。这些回复命令的行为方式取决于实现，且超出本文档的范围。特别是，当原消息带有"Reply-To:"字段时，是否在回复中包含原目标地址，本文档并未涉及。
3.6.4. 标识字段
尽管在第 3.6 节的表中列为可选，每条消息"应该"都有一个"Message-ID:"字段。此外，回复消息"应该"具有"In-Reply-To:"和"References:"字段（如适用并如下文描述）。
字段"Message-ID:"包含一个唯一的消息标识符。字段"References:"和"In-Reply-To:"各包含一个或多个唯一的消息标识符，可选地以 CFWS 分隔。
消息标识符（msg-id）语法是 addr-spec 构造的一个受限版本，括在尖括号字符"<"和">"之中。与 addr-spec 不同，此语法只允许"@"左侧使用 dot-atom-text 形式，并且在消息标识符的任何位置都不含内部 CFWS。
注意：与 addr-spec 一样，msg-id 的"@"右侧给出了宽松语法。然而，在本节稍后，推荐使用域作为"@"的右侧。同样，域构造的语法由其他协议（例如 [RFC1034]、[RFC1035]、[RFC1123]、[RFC5321]）规定并使用。因此，实现有责任在所使用语境下符合地址的语法。
message-id = "Message-ID:" msg-id CRLF in-reply-to = "In-Reply-To:" 1*msg-id CRLF references = "References:" 1*msg-id CRLF msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] id-left = dot-atom-text / obs-id-left id-right = dot-atom-text / no-fold-literal / obs-id-right no-fold-literal = "[" *dtext "]"
字段"Message-ID:"提供一个唯一的消息标识符，指代某个特定消息的某个特定版本。消息标识符的唯一性由生成它的主机保证（见下文）。此消息标识符旨在供机器读取，对人类不一定有意义。一个消息标识符恰好属于某个特定消息的一个版本；该消息的后续修订各自获得新的消息标识符。
注意：在许多情况下消息被"更改"，但这些更改并不构成该消息的新实例，因此消息不会获得新的消息标识符。例如，当消息被引入传输系统时，它们通常被前置额外的头字段，如跟踪字段（第 3.6.7 节描述）与重发字段（第 3.6.6 节描述）。此类头字段的添加并不改变消息的身份，因此保留原始的"Message-ID:"字段。在任何情况下，决定"Message-ID:"字段是否改变的是消息发送者希望传达的含义（即，这是同一条消息还是不同的消息），而不是消息中出现的（或没出现的）任何特定语法差异。
字段"In-Reply-To:"和"References:"在创建对一条消息的回复时使用。它们持有原消息的消息标识符，以及其他消息（例如，对一条本身也是回复的消息的回复）的消息标识符。字段"In-Reply-To:"可用于标识新消息所回复的消息（或消息），而字段"References:"可用于标识一段会话的"线索（thread）"。
创建对某消息的回复时，所得消息的"In-Reply-To:"和"References:"字段构造如下：
"In-Reply-To:"字段将包含本消息所回复的消息（"父消息"）的"Message-ID:"字段内容。如果存在多于一个父消息，则"In-Reply-To:"字段将包含所有父消息的"Message-ID:"字段内容。如果任何父消息中都没有"Message-ID:"字段，则新消息将没有"In-Reply-To:"字段。
"References:"字段将包含父消息的"References:"字段内容（若有），后跟父消息的"Message-ID:"字段内容（若有）。如果父消息不含"References:"字段但含有一个只含单个消息标识符的"In-Reply-To:"字段，则"References:"字段将包含父消息的"In-Reply-To:"字段内容，后跟父消息的"Message-ID:"字段内容（若有）。如果父消息没有任何"References:"、"In-Reply-To:"或"Message-ID:"字段，则新消息将没有"References:"字段。
注意：某些实现解析"References:"字段以显示"讨论线索"。这些实现假定每条新消息都是对单个父消息的回复，因此它们可以沿"References:"字段向后遍历，找到所列每条消息的父消息。因此，不鼓励为具有多个父消息的回复构造"References:"字段；如何做到这一点本文档并未定义。
消息标识符（msg-id）本身"必须"是消息的全局唯一标识符。消息标识符的生成者"必须"保证 msg-id 唯一。有若干算法可用于实现这一点。由于 msg-id 与 addr-spec 具有相似语法（除不允许 quoted-string、注释和折叠空白外完全相同），一种好的方法是将创建消息标识符的主机的域名（或域字面量 IP 地址）放在"@"的右侧（因为域名与 IP 地址通常是唯一的），并将当前绝对日期与时间，连同系统上其他当前唯一的（可能是顺序的）标识符（例如，进程 id 号）放在左侧。尽管其他算法也可行，但"建议"右侧包含某个域标识符（主机自身的或其他的），使得消息标识符的生成者能够在该域范围内保证左侧的唯一性。
在语义上，尖括号字符并非 msg-id 的一部分；msg-id 是两个尖括号字符之间的内容。
3.6.5. 信息字段
信息字段都是可选的。字段"Subject:"和"Comments:"是第 2.2.1 节定义的非结构化字段，因此可以包含文本或折叠空白。字段"Keywords:"包含一个或多个词或引用字符串的逗号分隔列表。
subject = "Subject:" unstructured CRLF
comments = "Comments:" unstructured CRLF
keywords = "Keywords:" phrase *("," phrase) CRLF
这三个字段旨在仅包含关于消息的、供人阅读的内容。字段"Subject:"最常见，包含一个标识消息主题的短字符串。在回复中使用时，字段体"可以"以字符串"Re: "（拉丁文"in re"的缩写，意为"关于"）开始，后跟原消息"Subject:"字段体的内容。如果这样做，只应使用字面字符串"Re: "的一个实例，因为使用其他字符串或超过一个实例可能导致不良后果。字段"Comments:"包含对消息主体文本的任何附加注释。字段"Keywords:"包含一个逗号分隔的重要词与短语的列表，可能对接收者有用。
3.6.6. 重发字段
重发（resent）字段"应该"被添加到任何由用户重新引入传输系统的消息中。每次这样做时"应该"添加一组独立的重发字段。对应于某次特定重发的所有重发字段"应该"被分组在一起。每组新的重发字段被前置到消息；也就是说，最新的一组重发字段出现在消息中更靠前的位置。添加重发字段时，消息中的其他字段不变。
每个重发字段对应于语法中其他位置的某个特定字段。例如，"Resent-Date:"字段对应于"Date:"字段，"Resent-To:"字段对应于"To:"字段。在每种情况下，字段体的语法与前面给出的相应字段语法相同。
使用重发字段时，"必须"发送"Resent-From:"和"Resent-Date:"字段。"应该"发送"Resent-Message-ID:"字段。如果"Resent-Sender:"与"Resent-From:"相同，则"不应"使用"Resent-Sender:"。
resent-date = "Resent-Date:" date-time CRLF resent-from = "Resent-From:" mailbox-list CRLF resent-sender = "Resent-Sender:" mailbox CRLF resent-to = "Resent-To:" address-list CRLF resent-cc = "Resent-Cc:" address-list CRLF resent-bcc = "Resent-Bcc:" [address-list / CFWS] CRLF resent-msg-id = "Resent-Message-ID:" msg-id CRLF
重发字段用于标识一条消息已被用户重新引入传输系统。使用重发字段的目的是让最终接收者看到的消息，仿佛是由原发送者直接发送的一样，所有原始字段保持不变。每组重发字段对应于一次特定的重发事件。也就是说，如果一条消息被重发多次，每组重发字段给出每次单独重发的信息。重发字段严格是信息性的。它们"不得"用于回复的正常处理或对消息的其他此类自动操作。
注意：将消息重新引入传输系统并使用重发字段，与"转发（forwarding）"是不同的操作。"Forwarding"有两种含义：一种意义上的转发是，邮件阅读程序可以被用户指示将消息的一份副本转发给另一人，使被转发的消息成为新消息的主体。这种意义上的转发消息看起来并非来自原发送者，而是来自转发者的全新消息。转发也可能意味着邮件传输程序收到一条消息并将其转发到另一个目的地以进行最终投递。重发头字段不打算用于这两种类型的转发。
重发发起者字段指明重发消息的个人或系统的邮箱。与常规发起者字段一样，有两种形式：简单的"Resent-From:"形式，包含执行重发的个人的邮箱；以及更复杂的形式，当一个人（在"Resent-Sender:"字段中标识）代表一个或多个其他人（在"Resent-From:"字段中标识）重发消息时。
注意：回复重发消息时，回复的行为与任何其他消息一样，使用原始的"From:"、"Reply-To:"、"Message-ID:"及其他字段。重发字段仅是信息性的，且"不得"用于回复的正常处理。
字段"Resent-Date:"指明重发消息被重发者发出的日期与时间。与"Date:"字段一样，它不是消息实际被传输的日期与时间。
字段"Resent-To:"、"Resent-Cc:"和"Resent-Bcc:"分别等同于字段"To:"、"Cc:"和"Bcc:"，区别在于它们指明的是重发消息的接收者，而非原消息的接收者。
字段"Resent-Message-ID:"为重发消息提供唯一标识符。
3.6.7. 跟踪字段
跟踪字段是一组头字段，由一个可选的"Return-Path:"字段和一个或多个"Received:"字段组成。字段"Return-Path:"包含一个括在尖括号中的可选 addr-spec。字段"Received:"包含一个（可能为空的）记号列表，后跟分号和 date-time 规范。每个记号必须是 word、angle-addr、addr-spec 或 domain。提供其使用规范的文档（如 [RFC5321]）对跟踪字段的语法施以进一步限制。
trace = [return]
1*received
return = "Return-Path:" path CRLF
path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS])
received = "Received:" *received-token ";" date-time CRLF
received-token = word / angle-addr / addr-spec / domain
关于 Internet 邮件对跟踪字段使用的完整讨论包含在 [RFC5321] 中。就本规范而言，跟踪字段严格是信息性的，对它们的任何形式化解释都在本文档的范围之外。
3.6.8. 可选字段
消息中可能出现本文档未另行规定的字段。它们必须符合 optional-field 的语法。这是一个由可打印 US-ASCII 字符（SP 与冒号除外）组成的字段名，后跟冒号，再后跟任何符合非结构化语法的文本。
任何可选字段的字段名"不得"与本文档其他地方规定的任何字段名相同。
optional-field = field-name ":" unstructured CRLF
field-name = 1*ftext
ftext = %d33-57 / ; Printable US-ASCII
%d59-126 ; characters not including
; ":".
就本规范而言，任何可选字段都未被解释。
4. 废弃语法
本规范的早期版本允许与当前版本不同的（通常更宽松的）语法。此外，Internet 上消息中还使用过一些语法元素，其解释从未被文档化。尽管根据第 3 节的文法"不得"生成这些语法形式，但符合规范的接收者"必须"接受并解析它们。本节记载了其中许多语法元素。取第 3 节的文法并加上本节给出的定义，即得到用于解释消息的文法。
注意：本节标识了任何实现"必须"合理解释的语法形式。然而，肯定存在不符合甚至本节所给出的附加语法的 Internet 消息。某个特定形式未出现在本文档的任何一节中，并不能成为计算机程序崩溃、或实现不可挽回地丢失畸形数据的理由。如何处理消息以保健壮，取决于实现本身。
废弃（解释用）语法与当前（生成用）语法之间的一个重要区别在于：在结构化头字段体（即，任何结构化头字段的冒号与 CRLF 之间）中，空白字符（包括折叠空白）与注释可以自由地插入到任何语法记号之间。这允许了许多复杂的、已被证明某些实现难以解析的形式。
废弃语法与当前语法的另一个关键区别在于：第 3.2.2 节关于由纯空白构成的行（在注释与折叠空白中）的规则不适用。见第 4.2 节下方关于折叠空白的讨论。
最后，本节出现了某些曾经被允许、但现已不允的字符。NUL 字符（ASCII 值 0）曾经被允许，但出于兼容性原因现已不再。同样，除 CR、LF、SP 和 HTAB 之外的 US-ASCII 控制字符（ASCII 值 1 至 8、11、12、14 至 31，以及 127）曾被允许出现在头字段体中。CR 和 LF 曾被允许以非 CRLF 的形式出现在消息中；此处也展示了这种用法。
语法与语义上的其他差异在以下各节中注明。
4.1. 杂项废弃记号
这些语法元素在废弃语法或主语法的其他地方使用。裸 CR、裸 LF 和 NUL 被加入 obs-qp、obs-body 和 obs-unstruct。US-ASCII 控制字符被加入 obs-qp、obs-unstruct、obs-ctext 和 obs-qtext。句点字符被加入 obs-phrase。obs-phrase-list 提供了一个（可能为空）的、可包含"空"元素的短语逗号分隔列表。也就是说，在这样的列表中可能有两个或更多逗号之间没有任何内容，或者逗号出现在列表的开头或末尾。
注意：obs-phrase 中的"句点"（或"句号"）字符（"."）并非本规范或任何其他规范的早期版本所允许的形式。句点（或来自 specials 的任何其他字符）都不允许出现在 phrase 中，因为它引入了区分 phrase 与 addr-spec 各部分之间的解析困难（见第 4.4 节）。它出现在此处，是因为句点字符当前在许多消息的地址显示名部分中被使用，尤其是用于姓名中的缩写，因此必须被正确解释。
obs-NO-WS-CTL = %d1-8 / ; US-ASCII control
%d11 / ; characters that do not
%d12 / ; include the carriage
%d14-31 / ; return, line feed, and
%d127 ; white space characters
obs-ctext = obs-NO-WS-CTL
obs-qtext = obs-NO-WS-CTL
obs-utext = %d0 / obs-NO-WS-CTL / VCHAR
obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR)
obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
obs-phrase = word *(word / "." / CFWS)
obs-phrase-list = [phrase / CFWS] *("," [phrase / CFWS])
裸 CR 与裸 LF 在消息中出现时具有两种不同的含义。在许多情况下，裸 CR 或裸 LF 被不当地用作 CRLF 的替代以指示行分隔符。在其他情况下，裸 CR 和裸 LF 仅被用作具有其传统 ASCII 含义的 US-ASCII 控制字符。
4.2. 废弃折叠空白
在废弃语法中，凡允许 obs-FWS 规则之处，都可以插入任意数量的折叠空白。这造成了在一行中出现两个连续"折叠"的可能，从而也造成构成折叠头字段的某一行可能完全由空白组成的可能。
obs-FWS = 1*WSP *(CRLF 1*WSP)
4.3. 废弃日期与时间
废弃日期格式的语法允许日期字段中使用 2 位年份，并允许使用本规范早期版本中使用过的字母时区说明符列表。它也允许在许多记号之间插入注释与折叠空白。
obs-day-of-week = [CFWS] day-name [CFWS]
obs-day = [CFWS] 1*2DIGIT [CFWS]
obs-year = [CFWS] 2*DIGIT [CFWS]
obs-hour = [CFWS] 2DIGIT [CFWS]
obs-minute = [CFWS] 2DIGIT [CFWS]
obs-second = [CFWS] 2DIGIT [CFWS]
obs-zone = "UT" / "GMT" / ; Universal Time
; North American UT
; offsets
"EST" / "EDT" / ; Eastern: - 5/ - 4
"CST" / "CDT" / ; Central: - 6/ - 5
"MST" / "MDT" / ; Mountain: - 7/ - 6
"PST" / "PDT" / ; Pacific: - 8/ - 7
%d65-73 / ; Military zones - "A"
%d75-90 / ; through "I" and "K"
%d97-105 / ; through "Z", both
%d107-122 ; upper and lower case
当日期中出现两位或三位年份时，年份按如下方式解释：如果遇到的两位年份其值介于 00 与 49 之间，则通过加 2000 解释该年份，得到介于 2000 与 2049 之间的值。如果遇到的两位年份其值介于 50 与 99 之间，或者遇到的是任何三位年份，则通过加 1900 解释该年份。
在废弃时区中，"UT"和"GMT"分别指示"Universal Time"和"Greenwich Mean Time"，在语义上都等同于"+0000"。
其余的三个字符时区是美国时区。第一个字母"E"、"C"、"M"或"P"分别代表"Eastern"（东部）、"Central"（中部）、"Mountain"（山地）和"Pacific"（太平洋）。第二个字母是"S"（代表"Standard"，标准时间）或"D"（代表"Daylight Savings"，夏令时）。它们的解释如下：
- EDT 在语义上等价于 -0400
- EST 在语义上等价于 -0500
- CDT 在语义上等价于 -0500
- CST 在语义上等价于 -0600
- MDT 在语义上等价于 -0600
- MST 在语义上等价于 -0700
- PDT 在语义上等价于 -0700
- PST 在语义上等价于 -0800
单字符军事时区在 [RFC0822] 中以非标准方式定义，因此其含义不可预测。军事时区"A"至"I"的原始定义分别等价于"+0100"至"+0900"；"K"、"L"和"M"分别等价于"+1000"、"+1100"和"+1200"；"N"至"Y"分别等价于"-0100"至"-1200"；而"Z"等价于"+0000"。然而，由于 [RFC0822] 中的错误，除非有带外信息确认其含义，否则它们都应被视为等价于"-0000"。
其他多字符（通常介于 3 至 5 个）字母时区已在 Internet 消息中使用过。任何含义未知的此类时区，除非有带外信息确认其含义，否则应被视为等价于"-0000"。
4.4. 废弃寻址
寻址方面有四个主要差异。第一，mailbox 地址在括于"<"和">"中时，允许在 addr-spec 之前有一个路由（route）部分。路由只是一个域名、各前带"@"的逗号分隔列表，并以冒号终止。第二，允许在 local-part 与 domain 的、以句点分隔的元素之间出现 CFWS（即，未使用 dot-atom）。此外，local-part 除 atom 外还允许包含 quoted-string。第三，mailbox-list 与 address-list 允许有"空"成员。也就是说，这样的列表中可能有两个或更多逗号之间没有任何内容，或逗号出现在列表的开头或末尾。最后，US-ASCII 控制字符与 quoted-pair 被允许出现在域字面量中，并在此加入。
obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS]
obs-route = obs-domain-list ":"
obs-domain-list = *(CFWS / ",") "@" domain
*("," [CFWS] ["@" domain])
obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS])
obs-addr-list = *([CFWS] ",") address *("," [address / CFWS])
obs-group-list = 1*([CFWS] ",") [CFWS]
obs-local-part = word *("." word)
obs-domain = atom *("." atom)
obs-dtext = obs-NO-WS-CTL / quoted-pair
解释地址时，路由部分"应该"被忽略。
4.5. 废弃头字段
在语法上，废弃字段语法的主要区别在于：它允许任何字段多次出现，且它们可以以任意顺序出现。此外，字段名末尾冒号之前允许任意数量的空白。
obs-fields = *(obs-return /
obs-received /
obs-orig-date /
obs-from /
obs-sender /
obs-reply-to /
obs-to /
obs-cc /
obs-bcc /
obs-message-id /
obs-in-reply-to /
obs-references /
obs-subject /
obs-comments /
obs-keywords /
obs-resent-date /
obs-resent-from /
obs-resent-send /
obs-resent-rply /
obs-resent-to /
obs-resent-cc /
obs-resent-bcc /
obs-resent-mid /
obs-optional)
除目标地址字段（第 4.5.3 节描述）外，字段多次出现的解释未予规定。同样，未作为前置到消息的块出现的跟踪字段与重发字段的解释也未予规定。除非以下各节另有说明，其他字段的解释与第 3 节中其非废弃对应字段的解释相同。
4.5.1. 废弃发起日期字段
obs-orig-date = "Date" *WSP ":" date-time CRLF
4.5.2. 废弃发起者字段
obs-from = "From" *WSP ":" mailbox-list CRLF obs-sender = "Sender" *WSP ":" mailbox CRLF obs-reply-to = "Reply-To" *WSP ":" address-list CRLF
4.5.3. 废弃目标地址字段
obs-to = "To" *WSP ":" address-list CRLF
obs-cc = "Cc" *WSP ":" address-list CRLF
obs-bcc = "Bcc" *WSP ":"
(address-list / (*([CFWS] ",") [CFWS])) CRLF
当消息中目标地址字段多次出现时，它们"应该"被视为：第一个出现的字段中的地址列表，通过添加逗号并连接，与后续出现的地址列表合并。
4.5.4. 废弃标识字段
废弃的"In-Reply-To:"和"References:"字段与当前语法的不同之处在于，它们允许出现短语（词或引用字符串）。msg-id 左右两侧的废弃形式允许穿插 CFWS，使它们在语法上分别等同于 local-part 与 domain。
obs-message-id = "Message-ID" *WSP ":" msg-id CRLF obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF obs-id-left = local-part obs-id-right = domain
就解释而言，"In-Reply-To:"和"References:"字段中的短语被忽略。
在语义上，local-part 与 domain 中的任何可选 CFWS 都不是 obs-id-left 与 obs-id-right 的一部分。
4.5.5. 废弃信息字段
obs-subject = "Subject" *WSP ":" unstructured CRLF obs-comments = "Comments" *WSP ":" unstructured CRLF obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
4.5.6. 废弃重发字段
废弃语法增加了一个"Resent-Reply-To:"字段，它由字段名、可选注释与折叠空白、冒号以及一个逗号分隔的地址列表组成。
obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
obs-resent-bcc = "Resent-Bcc" *WSP ":"
(address-list / (*([CFWS] ",") [CFWS])) CRLF
obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
与其他重发字段一样，"Resent-Reply-To:"字段仅作为跟踪信息处理。
4.5.7. 废弃跟踪字段
obs-return 与 obs-received 在此再次作为模板定义给出，正如第 3 节中的 return 与 received。它们的完整语法在 [RFC5321] 中给出。
obs-return = "Return-Path" *WSP ":" path CRLF obs-received = "Received" *WSP ":" *received-token CRLF
4.5.8. 废弃可选字段
obs-optional = field-name *WSP ":" unstructured CRLF
5. 安全考量
在终端或终端仿真器上显示消息时需要小心。功能强大的终端可能会对转义序列（escape sequences）和其他 US-ASCII 控制字符组合做出响应，带来各种后果。它们可以重映射键盘，或允许对终端进行其他修改，从而导致拒绝服务甚至数据损坏。它们可以触发（有时是可编程的）应答（answerback）消息，使一条消息能够代表接收者发出命令。它们还会影响终端附属设备（如打印机）的运行。消息查看者可能希望在显示前从消息中剥离潜在危险的终端转义序列。然而，其他转义序列出于有用目的出现在消息中（参见 [ISO.2022.1994]、[RFC2045]、[RFC2046]、[RFC2047]、[RFC2049]、[RFC4288]、[RFC4289]），因此不应不加区分地剥离。
在消息中传输非文本对象会引发额外的安全问题。这些问题在 [RFC2045]、[RFC2046]、[RFC2047]、[RFC2049]、[RFC4288] 和 [RFC4289] 中讨论。
许多实现使用第 3.6.3 节描述的"Bcc:"（盲复写副本）字段，以便在不向其他接收者透露一个或多个收件人地址的情况下，将消息发送给接收者。对此类"Bcc:"使用的不当处理，可能会泄露保密信息，最终通过知晓某个邮件地址的存在本身，导致安全问题。例如，如果使用第 3.6.3 节描述的第一种方法（即，从消息中移除"Bcc:"行），则盲收件人除了其地址未出现在消息头节中这一事实外，没有任何明确迹象表明自己收到过盲副本。因此，某个盲收件人可能潜在地向所有显示的接收者发送回复，并不慎暴露该消息曾发往盲收件人。当使用第 3.6.3 节的第二种方法时，盲收件人的地址出现在消息单独副本的"Bcc:"字段中。如果所发送的"Bcc:"字段包含所有盲收件人，则所有"Bcc:"接收者都将被每个"Bcc:"接收者看到。即使向每个"Bcc:"接收者单独发送只含个人地址的消息，实现仍须小心按照第 3.6.3 节处理对该消息的回复，以免不慎将盲收件人暴露给其他接收者。
6. IANA 考量
本文档更新了 [RFC4021] 中引用 [RFC2822] 定义的那些注册项。IANA 已按照 [RFC3864] 规定的流程，用以下头字段更新了永久消息头字段仓库（Permanent Message Header Field Repository）。
| 头字段名 | 适用协议 | 状态 | 规范文档 |
|---|---|---|---|
| Date | standard | 本文档（第 3.6.1 节） | |
| From | standard | 本文档（第 3.6.2 节） | |
| Sender | standard | 本文档（第 3.6.2 节） | |
| Reply-To | standard | 本文档（第 3.6.2 节） | |
| To | standard | 本文档（第 3.6.3 节） | |
| Cc | standard | 本文档（第 3.6.3 节） | |
| Bcc | standard | 本文档（第 3.6.3 节） | |
| Message-ID | standard | 本文档（第 3.6.4 节） | |
| In-Reply-To | standard | 本文档（第 3.6.4 节） | |
| References | standard | 本文档（第 3.6.4 节） | |
| Subject | standard | 本文档（第 3.6.5 节） | |
| Comments | standard | 本文档（第 3.6.5 节） | |
| Keywords | standard | 本文档（第 3.6.5 节） | |
| Resent-Date | standard | 本文档（第 3.6.6 节） | |
| Resent-From | standard | 本文档（第 3.6.6 节） | |
| Resent-Sender | standard | 本文档（第 3.6.6 节） | |
| Resent-To | standard | 本文档（第 3.6.6 节） | |
| Resent-Cc | standard | 本文档（第 3.6.6 节） | |
| Resent-Bcc | standard | 本文档（第 3.6.6 节） | |
| Resent-Reply-To | obsolete | 本文档（第 4.5.6 节） | |
| Resent-Message-ID | standard | 本文档（第 3.6.6 节） | |
| Return-Path | standard | 本文档（第 3.6.7 节） | |
| Received | standard | 本文档（第 3.6.7 节）；相关信息：[RFC5321] |
附录 A. 示例报文
本节给出一组消息示例。它们旨在协助本规范的实现，但不应被视为规范性（normative）的；也就是说，尽管本节中的示例经过仔细审阅，如果示例与本规范第 3 节和第 4 节描述的语法之间存在冲突，应以那些节中的语法为准。
在本文档的文本版本中，本节中的消息以"----"行之间的内容界定。"----"行本身不是消息的一部分。
A.1. 寻址示例
以下是两个人之间可能发送的消息示例。
A.1.1. 一人发给另一人、采用简单寻址的消息
这可称为一条典范（canonical）消息。它有一个作者 John Doe、一个接收者 Mary Smith、一个主题、日期、一个消息标识符，以及主体中的一段文本消息。
From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello".
如果 John 的秘书 Michael 实际发送了这条消息，尽管 John 是作者、且对此消息的回复应回到他那里，则会使用 sender 字段：
From: John Doe <jdoe@machine.example> Sender: Michael Jones <mjones@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello".
A.1.2. 不同类型的邮箱
此消息在目标字段中包含多个地址，并且使用了几种不同形式的地址。
From: "Joe Q. Public" <john.q.public@example.com> To: Mary Smith <mary@x.test>, jdoe@example.org, Who? <one@y.test> Cc: <boss@nil.test>, "Giant; \"Big\" Box" <sysservices@example.net> Date: Tue, 1 Jul 2003 10:52:37 +0200 Message-ID: <5678.21-Nov-1997@example.com> Hi everyone.
注意，Joe Q. Public 与 Giant; "Big" Box 的显示名需要用双引号括起来，因为前者包含句点，后者包含分号和双引号字符（双引号字符以 quoted-pair 构造形式出现）。相反，Who? 的显示名可以不用引号出现，因为问号在 atom 中是合法的。另请注意，jdoe@example.org 与 boss@nil.test 根本没有关联的显示名，而 jdoe@example.org 使用了不带尖括号的更简单地址形式。
A.1.3. 组地址
From: Pete <pete@silly.example> To: A Group:Ed Jones <c@a.test>,joe@where.test,John <jdoe@one.test>; Cc: Undisclosed recipients:; Date: Thu, 13 Feb 1969 23:32:54 -0330 Message-ID: <testabcd.1234@silly.example> Testing.
在此消息中，"To:"字段有一个名为"A Group"的单个组接收者，其中包含 3 个地址；以及一个名为 Undisclosed recipients 的空组接收者的"Cc:"字段。
A.2. 回复消息
以下是三条消息组成的一个系列，构成 John 与 Mary 之间的一段会话线索。John 首先向 Mary 发送一条消息，Mary 然后回复 John 的消息，接着 John 再回复 Mary 的回复消息。
请特别注意每条消息中的"Message-ID:"、"References:"和"In-Reply-To:"字段。
From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello".
发送回复时，Subject 字段通常被保留，尽管如第 3.6.5 节所述会前置"Re: "。
From: Mary Smith <mary@example.net> To: John Doe <jdoe@machine.example> Reply-To: "Mary Smith: Personal Account" <smith@home.example> Subject: Re: Saying Hello Date: Fri, 21 Nov 1997 10:01:10 -0600 Message-ID: <3456@example.net> In-Reply-To: <1234@local.machine.example> References: <1234@local.machine.example> This is a reply to your hello.
注意上面消息中的"Reply-To:"字段。当 John 回复 Mary 的上述消息时，回复应发往"Reply-To:"字段中的地址，而非"From:"字段中的地址。
To: "Mary Smith: Personal Account" <smith@home.example> From: John Doe <jdoe@machine.example> Subject: Re: Saying Hello Date: Fri, 21 Nov 1997 11:00:00 -0600 Message-ID: <abcd.1234@local.machine.test> In-Reply-To: <3456@example.net> References: <1234@local.machine.example> <3456@example.net> This is a reply to your reply.
A.3. 重发消息
从前面多次用作示例的那条消息开始：
From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello".
假设 Mary 在收到此消息后，希望将消息的一份副本发送给 Jane，使得（a）该消息看起来像直接来自 John；（b）如果 Jane 回复该消息，回复应回到 John；以及（c）所有原始信息，如消息最初发送给 Mary 的日期、消息标识符和原收件人，都被保留。在这种情况下，重发字段被前置到消息：
Resent-From: Mary Smith <mary@example.net> Resent-To: Jane Brown <j-brown@other.example> Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 Resent-Message-ID: <78910@example.net> From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello".
如果 Jane 反过来希望将此消息重发给另一人，她会把自己的那组重发头字段前置到上面的消息并发送。（注意，为简洁起见，未显示跟踪字段。）
A.4. 带跟踪字段的消息
当消息如 [RFC5321] 所述通过传输系统发送时，跟踪字段被前置到消息。以下这些跟踪字段可能呈现的样子。注意第一个中有一些折叠空白，因为这些行可能很长。
Received: from x.y.test by example.net via TCP with ESMTP id ABC12345 for <mary@example.net>; 21 Nov 1997 10:05:43 -0600 Received: from node.example by x.y.test; 21 Nov 1997 10:01:22 -0600 From: John Doe <jdoe@node.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: Fri, 21 Nov 1997 09:55:06 -0600 Message-ID: <1234@local.node.example> This is a message just to say hello. So, "Hello".
A.5. 空白、注释与其他奇特之处
空白（包括折叠空白）和注释可以插入到字段的许多记号之间。以 A.1.3 的示例为例，空白与注释可以插入到所有字段中。
From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
To:A Group(Some people)
:Chris Jones <c@(Chris's host.)public.example>,
joe@example.org,
John <jdoe@one.test> (my dear friend); (the end of the group)
Cc:(Empty list)(start)Hidden recipients :(nobody(that I know)) ;
Date: Thu,
13
Feb
1969
23:32
-0330 (Newfoundland Time)
Message-ID: <testabcd.1234@silly.test>
Testing.
上面的示例在审美上令人不快，但完全合法。特别请注意：（1）"From:"字段中的注释（包括一个以 quoted-pair 形式出现的")"字符）；（2）"To:"字段冒号之后缺失的空白，以及组名之后的注释和折叠空白，Chris Jones 地址中注释里的特殊字符（"."），以及"joe@example.org,"前后（的折叠空白）；（3）"Cc:"字段中多个嵌套的注释，以及"Cc"之后冒号紧邻的注释；（4）折叠空白（但除末尾外无注释）以及日期时间中缺失的秒；（5）"Message-ID:"字段标识符之前（而非之内）的空白。
A.6. 已废弃的形式
以下是本规范第 4 节描述的废弃（即"不得生成"的）语法元素的示例。
A.6.1. 废弃寻址
请注意下面示例中对 Joe Q. Public 缺少引号、Mary Smith 地址中出现的路由、在"To:"字段中出现的两个逗号，以及 jdoe 地址中"."周围出现的空格。
From: Joe Q. Public <john.q.public@example.com> To: Mary Smith <@node.test:mary@example.net>, , jdoe@test . example Date: Tue, 1 Jul 2003 10:52:37 +0200 Message-ID: <5678.21-Nov-1997@example.com> Hi everyone.
A.6.2. 废弃日期
以下消息使用了废弃日期格式，包括非数字时区与两位年份。注意，尽管缺少 day-of-week，但这并非废弃语法所特有；在当前语法中它也是可选的。
From: John Doe <jdoe@machine.example> To: Mary Smith <mary@example.net> Subject: Saying Hello Date: 21 Nov 97 09:55:06 GMT Message-ID: <1234@local.machine.example> This is a message just to say hello. So, "Hello".
A.6.3. 废弃空白与注释
空白与注释可以出现在比当前语法中更多的元素之间。此外，完全由空白组成的折行是合法的。
From : John Doe <jdoe@machine(comment). example>
To : Mary Smith
__
<mary@example.net>
Subject : Saying Hello
Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600
Message-ID : <1234 @ local(blah) .machine .example>
This is a message just to say hello.
So, "Hello".
请特别注意"To:"字段的第二行。它以两个空格字符开始。（注意"__"代表空白字符。）因此，如第 4.2 节所述，它被视为折叠的一部分。此外，地址、日期和消息标识符中的注释与空白全都是废弃语法的一部分。
附录 B. 与早期规范的差异
本附录列出 Internet 报文格式相对于早期规范（具体为 [RFC0822]、[RFC1123] 和 [RFC2822]）所做的变更清单。以下标有星号（*）的条目出现在本文档第 4 节中，因此不能再被生成。
以下是从 [RFC0822] 与 [RFC1123] 到 [RFC2822]、并在本文档中保留的变更：
- 在 phrase 的废弃形式中允许句点。
- ABNF 移出文档，现位于 [RFC5234]。
- 年份允许四位或更多位数字。
- 明确（缺失的）头字段排序。
- 移除 Encrypted 头字段。
- 特别允许并赋予"-0000"时区以含义。
- 不允许在每个记号之间使用折叠空白。
- 移除对目标字段的要求。
- 重新定义转发与重发。
- 不再单独指出扩展头字段。
- 移除 ASCII 0（null）。*
- 折叠续行不能仅含空白。*
- 日期中不允许自由插入注释。*
- 不允许非数字时区。*
- 不允许两位年份。*
- 三位年份可解释，但不允许用于生成。*
- 不允许地址中的路由。*
- 不允许 local-part 与 domain 内的 CFWS。*
- 不允许地址列表中的空成员。*
- 不允许字段名与冒号之间的折叠空白。*
- 不允许字段名与冒号之间的注释。
- 收紧 in-reply-to 与 references 的语法。*
- 不允许 msg-id 内的 CFWS。*
- 收紧重发字段的语义，仅为信息性。
- 不允许 Resent-Reply-To。*
- 字段不得多次出现（resent 与 received 除外）。*
- 不允许自由的 CR 与 LF。*
- 规定行长度限制。
- 更清晰地规定 Bcc。
以下是从 [RFC2822] 起的变更：
- 修正各类排印/语法错误并作出澄清。
- 全文将"standard"改为"document"或"specification"。
- 区分"header field"与"header section"。
- 从 ctext、qtext、dtext 和 unstructured 中移除 NO-WS-CTL。*
- 将 specials 的讨论移至"Atom"节，将文本移至"整体报文语法"节。
- 简化 CFWS 语法。
- 修正 unstructured 语法。
- 更改日期与时间语法以处理废弃日期语法中的空白。
- 从域字面量与消息标识符中移除 quoted-pair。*
- 澄清其他规范限制了域语法。
- 简化"Bcc:"与"Resent-Bcc:"语法。
- 允许 optional-field 出现在跟踪信息中。
- 从 msg-id 移除 no-fold-quote。澄清语法限制。
- 一般化"Received:"语法以修复缺陷，并将定义移出本文档。
- 简化 obs-qp。修正并简化 obs-utext（现仅出现在废弃语法中）。移除 obs-text 与 obs-char，加入 obs-body。
- 修正废弃日期语法以允许更多（或更少）注释与空白。
- 修正所有废弃列表语法（obs-domain-list、obs-mbox-list、obs-addr-list、obs-phrase-list，以及新加入的 obs-group-list）。
- 修正 obs-reply-to 语法。
- 修正 obs-bcc 与 obs-resent-bcc 以允许空列表。
- 移除 obs-path。
附录 C. 致谢
许多人参与了本文档的工作。其中包括参与 Internet 工程任务组（IETF）详细修订与更新消息标准（DRUMS）工作组的人员、DRUMS 的主席、IETF 的领域总监，以及仅通过电子邮件发送意见的人士。编辑深表感激，并真诚感谢他们所有人。以下列表包含就本文档以及 [RFC2822] 发送过电子邮件的每一个人。希望能在此处列出每位贡献者的名字：
| Matti Aarnio | Tanaka Akira | Russ Allbery |
| Eric Allman | Harald Alvestrand | Ran Atkinson |
| Jos Backus | Bruce Balden | Dave Barr |
| Alan Barrett | John Beck | J Robert von Behren |
| Jos den Bekker | D J Bernstein | James Berriman |
| Oliver Block | Norbert Bollow | Raj Bose |
| Antony Bowesman | Scott Bradner | Randy Bush |
| Tom Byrer | Bruce Campbell | Larry Campbell |
| W J Carpenter | Michael Chapman | Richard Clayton |
| Maurizio Codogno | Jim Conklin | R Kelley Cook |
| Nathan Coulter | Steve Coya | Mark Crispin |
| Dave Crocker | Matt Curtin | Michael D'Errico |
| Cyrus Daboo | Michael D Dean | Jutta Degener |
| Mark Delany | Steve Dorner | Harold A Driscoll |
| Michael Elkins | Frank Ellerman | Robert Elz |
| Johnny Eriksson | Erik E Fair | Roger Fajman |
| Patrik Faltstrom | Claus Andre Faerber | Barry Finkel |
| Erik Forsberg | Chuck Foster | Paul Fox |
| Klaus M Frank | Ned Freed | Jochen Friedrich |
| Randall C Gellens | Sukvinder Singh Gill | Tim Goodwin |
| Philip Guenther | Arnt Gulbrandsen | Eric A Hall |
| Tony Hansen | John Hawkinson | Philip Hazel |
| Kai Henningsen | Robert Herriot | Paul Hethmon |
| Jim Hill | Alfred Hoenes | Paul E Hoffman |
| Steve Hole | Kari Hurtta | Marco S Hyman |
| Ofer Inbar | Olle Jarnefors | Kevin Johnson |
| Sudish Joseph | Maynard Kang | Prabhat Keni |
| John C Klensin | Graham Klyne | Brad Knowles |
| Shuhei Kobayashi | Peter Koch | Dan Kohn |
| Christian Kuhtz | Anand Kumria | Steen Larsen |
| Eliot Lear | Barry Leiba | Jay Levitt |
| Bruce Lilly | Lars-Johan Liman | Charles Lindsey |
| Pete Loshin | Simon Lyall | Bill Manning |
| John Martin | Mark Martinec | Larry Masinter |
| Denis McKeon | William P McQuillan | Alexey Melnikov |
| Perry E Metzger | Steven Miller | S Moonesamy |
| Keith Moore | John Gardiner Myers | Chris Newman |
| John W Noerenberg | Eric Norman | Mike O'Dell |
| Larry Osterman | Paul Overell | Jacob Palme |
| Michael A Patton | Uzi Paz | Michael A Quinlan |
| Robert Rapplean | Eric S Raymond | Sam Roberts |
| Hugh Sasse | Bart Schaefer | Tom Scola |
| Wolfgang Segmuller | Nick Shelness | John Stanley |
| Einar Stefferud | Jeff Stephenson | Bernard Stern |
| Peter Sylvester | Mark Symons | Eric Thomas |
| Lee Thompson | Karel De Vriendt | Matthew Wall |
| Rolf Weber | Brent B Welch | Dan Wing |
| Jack De Winter | Gregory J Woodhouse | Greg A Woods |
| Kazu Yamamoto | Alain Zahm | Jamie Zawinski |
| Timothy S Zurcher |
7. 参考文献
7.1. 规范性参考文献
- [ANSI.X3-4.1986] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
- [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
- [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
7.2. 资料性参考文献
- [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
- [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
- [ISO.2022.1994] International Organization for Standardization, "Information technology - Character code structure and extension techniques", ISO Standard 2022, 1994.
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
- [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
- [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
- [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
- [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
- [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
- [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, March 2005.
- [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
- [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 4289, December 2005.
- [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
作者地址
Peter W. Resnick（编辑）
Qualcomm Incorporated
5775 Morehouse Drive
San Diego, CA 92121-1714
US
电话：+1 858 651 4478
电子邮件：presnick@qualcomm.com
URI：http://www.qualcomm.com/~presnick/
版权声明
Copyright (C) The IETF Trust (2008).
本文档受 BCP 78 所含的权利、许可与限制约束，除其中另有规定外，作者保留其全部权利。
本文档及其所含信息按"原样（AS IS）"提供，贡献者、其代表或赞助的组织（若有）、互联网协会、IETF 信托以及互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何关于使用本文档信息不侵犯任何权利的保证，以及任何关于适销性或特定用途适用性的暗示保证。
知识产权
IETF 对可能声称与实现或使用本文档所述技术相关的任何知识产权或其他权利的有效性或范围不持立场，也不表示其已做出任何独立努力来识别任何此类权利。关于 RFC 文档中权利相关程序的更多信息，见 BCP 78 与 BCP 79。
向 IETF 秘书处提交的 IPR 披露副本、任何许可保证，或实现者或用户为获取使用此类专有权利的通用许可或权限所做尝试的结果，可从 IETF 在线 IPR 仓库 http://www.ietf.org/ipr 获取。
IETF 邀请任何相关方将其注意到的、可能涵盖实现本标准所需技术的任何版权、专利或专利申请，或其他专有权利，提请 IETF 注意，地址：ietf-ipr@ietf.org。