Skip to main content

1. Introduction (简介)

自1982年发布以来, RFC 822已经定义了互联网上文本邮件消息的标准格式. 其成功之处在于RFC 822格式已被广泛采用, 无论是完整采用还是部分采用, 都远远超出了互联网和RFC 821定义的互联网SMTP传输的范围. 随着该格式得到更广泛的使用, 许多限制对用户社区来说已被证明越来越具有限制性.

RFC 822旨在指定文本消息的格式. 因此, 非文本消息 (如可能包含音频或图像的多媒体消息) 根本没有被提及. 然而, 即使在文本的情况下, RFC 822也不足以满足邮件用户的需求, 这些用户的语言需要使用比US-ASCII更丰富的字符集. 由于RFC 822没有为包含音频、视频、亚洲语言文本, 甚至大多数欧洲语言文本的邮件指定机制, 因此需要额外的规范.

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

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

本文档描述了几种机制, 这些机制结合起来可以在不引入任何与现有RFC 822邮件世界的严重不兼容的情况下解决这些问题中的大多数. 特别是, 它描述了:

  1. MIME-Version头部字段 (MIME-Version header field), 它使用版本号声明消息符合MIME, 并允许邮件处理代理将此类消息与由较旧或不符合要求的软件生成的消息区分开来, 后者被认为缺少这样的字段.

  2. Content-Type头部字段 (Content-Type header field), 从RFC 1049推广而来, 可用于指定消息正文中数据的媒体类型和子类型, 并完全指定此类数据的本机表示 (规范形式, canonical form).

  3. Content-Transfer-Encoding头部字段 (Content-Transfer-Encoding header field), 可用于指定应用于正文的编码转换以及结果的域. 除了恒等转换之外的编码转换通常应用于数据, 以允许其通过可能具有数据或字符集限制的邮件传输机制.

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

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

最后, 为了指定和促进互操作性, RFC 2049为上述机制的子集提供了基本的适用性声明, 该子集定义了与本文档的最低"一致性"级别.

历史注释: 本文档集中描述的几种机制在初读时可能看起来有些奇怪甚至巴洛克式. 重要的是要注意, 与现有标准的兼容性以及跨现有实践的鲁棒性是开发这套文档的工作组的两个最高优先级. 特别是, 兼容性始终优先于优雅性.

请参考"互联网官方协议标准"的当前版本, 了解本协议的标准化状态. RFC 822和STD 3、RFC 1123也为MIME提供了基本背景, 因为任何符合MIME的实现都不能违反它们. 此外, 其他几个信息性RFC文档对MIME实现者也很有价值, 特别是RFC 1344、RFC 1345和RFC 1524.

术语表:

  • User Agent (UA): 用户代理, 用户用于发送和接收邮件的程序
  • MIME: Multipurpose Internet Mail Extensions (多用途互联网邮件扩展)
  • canonical form: 规范形式
  • media type: 媒体类型
  • subtype: 子类型
  • encoding transformation: 编码转换

关键概念:

  • RFC 822的局限性: 仅支持7位US-ASCII文本
  • MIME的目标: 支持多媒体、多字符集、非文本内容
  • 兼容性优先: MIME设计保持与RFC 822的向后兼容
Last updated on