跳到主要内容

1. 引言

自 1982 年发布以来, RFC 822 一直定义 Internet 上文本邮件消息的标准格式. 它非常成功, 以至于 RFC 822 格式已经在 Internet 以及 RFC 821 定义的 Internet SMTP 传输范围之外被全部或部分采用. 随着该格式被广泛采用, 一些限制对用户社区而言变得越来越具有约束性.

RFC 822 旨在规定文本消息的格式. 因此, 它完全没有提及非文本消息, 例如可能包含音频或图像的多媒体消息. 然而, 即使对于文本, RFC 822 也无法满足那些语言需要使用比 US-ASCII 更丰富字符集的邮件用户需求. 由于 RFC 822 没有规定包含音频, 视频, 亚洲语言文本, 甚至大多数欧洲语言文本的邮件机制, 因此需要额外规范.

基础 RFC 821/822 邮件系统的一个显著限制是, 它们把电子邮件消息内容限制为 7bit US-ASCII 的较短行 (例如 1000 个字符或更少 [RFC-821]). 这迫使用户在调用本地邮件 UA (User Agent, 用户代理, 人类用户用来收发邮件的程序) 之前, 将他们希望发送的任何非文本数据转换为可表示为可打印 US-ASCII 字符的七位字节. 当前 Internet 中使用的这类编码示例包括纯十六进制, uuencode, RFC 1421 规定的 3-in-4 base64 方案, Andrew Toolkit Representation [ATK] 以及许多其他编码.

当设计网关以允许在 RFC 822 主机和 X.400 主机之间交换邮件消息时, RFC 822 邮件格式的限制变得更加明显. X.400 [X400] 规定了在电子邮件消息中包含非文本材料的机制. 当前将 X.400 消息映射到 RFC 822 消息的标准规定, X.400 非文本材料必须转换为 (而不是编码为) IA5Text 格式, 或者被丢弃, 并通知 RFC 822 用户已经发生丢弃. 这显然不可取, 因为用户可能希望接收的信息会丢失. 即使用户代理没有能力处理非文本材料, 用户也可能拥有 UA 外部的某种机制, 能够从该材料中提取有用信息. 此外, 这种做法没有考虑到消息最终可能被网关转回 X.400 消息处理系统 (即 X.400 消息通过 Internet mail 被 "tunneled"), 在那里非文本信息肯定会再次变得有用.

本文档描述了若干机制, 它们组合起来可以解决大多数这些问题, 同时不会与现有 RFC 822 邮件世界引入任何严重不兼容. 具体而言, 它描述:

  1. MIME-Version 头字段, 它使用版本号声明消息符合 MIME, 并允许邮件处理代理区分这类消息和由较旧或不符合 MIME 的软件生成的消息; 后者被假定缺少该字段.

  2. Content-Type 头字段, 它从 RFC 1049 泛化而来, 可用于指定消息正文中数据的 media type (媒体类型) 和 subtype (子类型), 并完整指定这类数据的 native representation (原生表示, canonical form).

  3. Content-Transfer-Encoding 头字段, 它可用于同时指定应用于正文的 encoding transformation (编码转换) 以及结果所在的域. 除恒等转换以外的编码转换通常会应用于数据, 以允许数据通过可能存在数据或字符集限制的邮件传输机制.

  4. 两个额外头字段, Content-ID 和 Content-Description, 可用于进一步描述正文中的数据.

本文档定义的所有头字段都受 RFC 822 中规定的头字段通用语法规则约束. 特别是, 除 Content-Disposition 外, 所有这些头字段都可以包含 RFC 822 注释; 这些注释没有语义内容, 在 MIME 处理期间应被忽略.

最后, 为了规定并促进互操作性, RFC 2049 为上述机制的一个子集提供了基本适用性声明, 为当前文档定义最低 "conformant" (符合) 级别.

历史说明: 本文档集描述的若干机制初读时可能显得有些奇怪, 甚至繁复. 需要注意, 与现有标准的兼容性以及跨既有实践的健壮性, 是开发本文档集的工作组最优先考虑的两个目标. 尤其是, 兼容性始终优先于优雅性.

请参考当前版本的 "Internet Official Protocol Standards", 了解本协议的标准化阶段和状态. RFC 822 以及 STD 3, RFC 1123 也为 MIME 提供重要背景, 因为任何符合 MIME 的实现都不能违反它们. 此外, 其他若干信息性 RFC 文档对 MIME 实现者也很有价值, 尤其是 RFC 1344, RFC 1345 和 RFC 1524.

术语:

  • User Agent (UA, 用户代理): 人类用户用来收发邮件的程序
  • MIME: Multipurpose Internet Mail Extensions (多用途 Internet 邮件扩展)
  • canonical form (规范形式): 数据的原生表示
  • media type (媒体类型): 数据的一般类型
  • subtype (子类型): 媒体类型内的具体格式
  • encoding transformation (编码转换): 为传输而应用于数据的转换

关键概念:

  • RFC 822 限制: 仅支持 7-bit US-ASCII 文本
  • MIME 目标: 支持多媒体, 多字符集和非文本内容
  • 兼容性优先: MIME 设计保持与 RFC 822 的向后兼容
最后于 更新