email — 电子邮件与 MIME 处理包¶
email 包是一个用于管理电子邮件消息的库。它专门设计为*不*做任何发送电子邮件消息到 SMTP (RFC 2821)、NNTP 或其他服务器的操作；这些是 smtplib 等模块的功能。email 包试图尽可能地兼容 RFC，支持 RFC 5322 和 RFC 6532，以及 MIME 相关的 RFC，如 RFC 2045、RFC 2046、RFC 2047、RFC 2183 和 RFC 2231。
email 包的整体结构可以分为三个主要部分，外加第四个部分，用于控制其他部分的行为。
该包的核心组件是一个表示电子邮件消息的“对象模型”。应用程序主要通过 message 子模块中定义的对象模型接口与该包进行交互。应用程序可以使用此 API 来查询现有电子邮件、构造新电子邮件，或添加/删除同样使用该对象模型接口的电子邮件子组件。也就是说，遵循电子邮件及其 MIME 子组件的特性，email 对象模型是一个由提供 EmailMessage API 的对象组成的树状结构。
该包的另外两个主要组件是 parser（解析器）和 generator（生成器）。解析器接收电子邮件消息的序列化版本（一个字节流），并将其转换为一个由 EmailMessage 对象组成的树。生成器则接收一个 EmailMessage 对象，并将其转换回序列化的字节流。（解析器和生成器也处理文本字符流，但不鼓励这种用法，因为它很容易导致消息在某方面无效。）
控制组件是 policy 模块。每个 EmailMessage、每个 generator 和每个 parser 都有一个关联的 policy 对象来控制其行为。通常，应用程序只需在创建 EmailMessage 时指定策略，无论是通过直接实例化 EmailMessage 来创建新邮件，还是使用 parser 解析输入流。但是，当使用 generator 序列化消息时，可以更改策略。例如，这允许从磁盘解析一封通用的电子邮件消息，但在将其发送到电子邮件服务器时，使用标准的 SMTP 设置进行序列化。
email 包尽力向应用程序隐藏各种管理性 RFC 的细节。从概念上讲，应用程序应该能够将电子邮件消息视为一个由 Unicode 文本和二进制附件组成的结构化树，而不必担心这些内容在序列化时如何表示。然而，在实践中，通常需要了解至少一些管理 MIME 消息及其结构的规则，特别是 MIME “内容类型”的名称和性质，以及它们如何标识多部分文档。大多数情况下，这些知识仅对于更复杂的应用程序是必需的，即便如此，也应该只关注高层结构，而不是这些结构如何表示的细节。由于 MIME 内容类型在现代互联网软件（不仅仅是电子邮件）中广泛使用，这对许多程序员来说将是一个熟悉的概念。
以下各节描述了 email 包的功能。我们从 message 对象模型开始，这是应用程序将使用的主要接口，然后是 parser 和 generator 组件。接着，我们介绍 policy 控制，从而完成对该库主要组件的论述。
接下来的三个部分涵盖了该包可能引发的异常以及 parser 可能检测到的缺陷（不符合 RFC 的情况）。然后我们介绍 headerregistry 和 contentmanager 子组件，它们分别提供了用于更详细地操作标头和有效载荷的工具。这两个组件都包含了与消费和生成复杂消息相关的功能，同时也记录了它们的可扩展性 API，这对于高级应用程序会很有用。
接下来是一组使用前面章节中介绍的 API 基本部分的示例。
以上内容代表了 email 包的现代（Unicode 友好）API。其余部分从 Message 类开始，涵盖了旧版的 compat32 API，该 API 更直接地处理电子邮件消息的表示细节。compat32 API *不*向应用程序隐藏 RFC 的细节，但对于需要在此级别上操作的应用程序，它们可以是有用的工具。本文档对于仍在使用 compat32 API 以实现向后兼容的应用程序也同样适用。
在 3.6 版更改: 文档经过重组和重写，以推广新的 EmailMessage/EmailPolicy API。
email 包文档内容
旧版 API