跳到主要内容

4. 术语

本文档假定读者对 RFC 5321 [RFC5321] 和 RFC 5322 [RFC5322] 所述核心电子邮件标准中的协议和术语具有适当了解.

4.1 邮件用户代理与邮件传输代理​

本文档的大部分说明依赖于 "邮件传输代理"("MTA")和 "邮件用户代理"("MUA")这两个抽象概念. 不过必须理解, 这些术语及其背后的概念出现于 Internet 电子邮件体系结构设计之后, 也晚于 "线上协议" 原则在该体系结构中的应用. 随着电子邮件体系结构的演进, 这一体系结构和 "线上协议" 原则一直使人们无法对 MTA 与 MUA 在某个源主机或目标主机上如何交互(乃至它们是否彼此独立)作出明确且标准化的区分.

不过, 本文档使用的 "最终投递 MTA" 一词, 与 RFC 5321 中的 "投递系统" 或 "最终投递系统" 含义相同. 它是控制地址本地部分格式, 并被允许检查和解释该部分的 SMTP 服务器. 它从网络接收消息, 将其投递到邮箱或执行其他本地处理, 包括会更改信封地址的任何转发或别名处理, 而不是继续中继. 从网络的角度看, 保存到消息存储, 移交给特定消息投递程序或代理, 以及检索消息的机制等一切本地投递安排, 都位于最终投递 MTA "之后", 因而不属于 SMTP 传输或投递过程.

4.2 地址字符集​

在本文档中, 如果地址的每个字符都属于 ASCII 字符表 [ASCII], 则该地址称为 "全 ASCII 地址" 或简称 "ASCII 地址". 如果其中任何字符不属于 ASCII 字符表, 则称为 "非 ASCII 地址" 或 "i18n 地址". 这类地址 MAY 受到其他限制, 但这些限制与本定义无关. 当这种区分很重要时, "全 ASCII" 一词也适用于其他协议元素, 其反义词为 "非 ASCII" 或 "国际化".

用于统称本文档及其配套文档所规定的电子邮件地址国际化技术的术语是 "SMTPUTF8". 例如, 本规范允许的地址称为 "符合 SMTPUTF8 的地址".

请注意, 按照上述定义, 所有 "全 ASCII" 地址组成的集合与所有 "非 ASCII" 地址组成的集合互斥. 使用 SMTPUTF8 时允许的全部地址集合, 是这两个集合的并集.

4.3 用户类型​

"ASCII 用户" 满足以下两项条件: (i) 仅使用只包含 ASCII 字符的电子邮件地址; (ii) 无法生成包含非 ASCII 字符的收件人地址.

"国际化电子邮件用户" 拥有一个或多个非 ASCII 电子邮件地址, 或者能够生成包含非 ASCII 字符的收件人地址. 这类用户也可能拥有 ASCII 地址. 如果用户拥有多个电子邮件账户及其对应地址, 或同一地址拥有多个别名, 则该用户可以通过某种方式选择外发邮件使用的地址. 请注意, 根据本定义, 仅凭一个 ASCII 地址无法判断其所有者是否为国际化电子邮件用户. 非 ASCII 地址则表示发件人相信该地址的所有者是国际化电子邮件用户. 不存在所谓 "国际化电子邮件用户消息", 该术语只适用于用户及其代理和能力. 特别是, 非 ASCII 的消息内容(因而通常也是国际化内容)本来就是 MIME 规范 [RFC2045] 的组成部分, 并不需要这些扩展, 但与这些扩展兼容.

4.4 消息​

"消息" 是由一个用户(发件人)使用某个特定电子邮件地址, 发送给一个或多个其他收件人电子邮件地址的内容. 收件人也常简称为 "用户" 或 "收件用户".

4.5 邮件列表​

"邮件列表" 是一种机制, 通过向一个收件人地址发送消息, 可将该消息分发给多个收件人. 位于这个单一地址的代理(通常不是人)随后促使消息重新分发给目标收件人. 该代理会把重新分发消息的信封返回地址设置为不同于原始单一收件人消息的地址. 使用不同的信封返回地址(反向路径), 可使错误消息以及其他自动生成的消息发往专门的错误处理地址.

针对可能包含非 ASCII 地址的邮件列表, 专门讨论该主题的文档 [RFC5983] 及其预期后继文档 [RFC5983bis-MailingList] 给出了特殊管理规定.

4.6 传统消息与国际化消息​

  • 传统消息不使用本规范集合中的 SMTP 扩展文档 [RFC6531] 或 UTF8header 文档 [RFC6532] 所定义的任何扩展, 并严格符合 RFC 5322 [RFC5322].

  • 国际化消息使用本规范集合定义的一个或多个扩展, 因而不再符合传统的电子邮件消息或其传输规范.

4.7 无法投递的消息, 通知与投递回执​

按照 RFC 5321 的规定, 因某种原因无法投递的消息应当导致向发件人发送通知. 通知可能通过两种方式之一发生. 第一种通常称为 "拒绝", 即 SMTP 服务器返回表示致命错误的回复码("5yz" 代码), 或持续返回临时失败错误("4yz" 代码). 第二种是在 SMTP 处理期间接受消息, 随后向发件人生成一条消息, 通常称为 "未投递通知" 或 "NDN". 当前实践通常倾向于拒绝而不是 NDN, 因为这样可以降低生成 NDN 被用作垃圾邮件手段的可能性. 如果中间 MTA 接受一条消息, 而下一跳服务器随后拒绝该消息, 则后一种 NDN 情形不可避免.

发件人还 MAY 明确请求消息回执 [RFC3461]. 对这些国际化扩展而言, 这会引发与 NDN 相同的问题.