email — 电子邮件和 MIME 处理包¶
email 包是一个用于管理电子邮件消息的库。它专门不用于将任何电子邮件消息发送到 SMTP（RFC 2821）、NNTP 或其他服务器；这些是 smtplib 和 nntplib 等模块的功能。email 包试图尽可能符合 RFC，支持 RFC 5322 和 RFC 6532，以及与 MIME 相关的 RFC，如 RFC 2045、RFC 2046、RFC 2047、RFC 2183 和 RFC 2231。
email 包的整体结构可以分为三个主要组件，以及第四个控制其他组件行为的组件。
该包的核心组件是一个表示电子邮件消息的“对象模型”。应用程序主要通过 message 子模块中定义的对象模型接口与包进行交互。应用程序可以使用此 API 询问有关现有电子邮件的问题，构造新的电子邮件，或添加或删除本身使用相同对象模型接口的电子邮件子组件。也就是说，遵循电子邮件消息及其 MIME 子组件的性质，电子邮件对象模型是一个对象树结构，所有对象都提供 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 控件，它完成了对库主要组件的处理。
接下来的三节将介绍该软件包可能引发的异常以及 解析器 可能检测到的缺陷（不符合 RFC）。然后，我们将介绍 headerregistry 和 contentmanager 子组件，它们分别提供了用于对标头和有效负载进行更详细操作的工具。这两个组件都包含与使用和生成非平凡消息相关的功能，但也记录了它们的扩展性 API，这将是高级应用程序感兴趣的。
接下来是一组使用前面几节中介绍的 API 基本部分的示例。
以上内容代表了电子邮件包的现代（Unicode 友好）API。其余部分，从 Message 类开始，涵盖了传统的 compat32 API，该 API 更直接地处理电子邮件消息表示方式的细节。compat32 API *不会* 对应用程序隐藏 RFC 的细节，但对于需要在该级别操作的应用程序来说，它们可能是有用的工具。此文档也与出于向后兼容性原因仍在使用 compat32 API 的应用程序相关。
在 3.6 版更改: 重新组织和重写了文档，以推广新的 EmailMessage/EmailPolicy API。
email 包文档的内容
传统 API