email —电子邮件和 MIME 处理包
源代码： Lib/email/init.py
email软件包是用于 Management 电子邮件的库。它不是专门设计用于将电子邮件发送到 SMTP( RFC 2821)，NNTP 或其他服务器；这些是smtplib和nntplib等模块的Function。 email包try尽可能地符合 RFC，支持 RFC 5233和 RFC 6532，以及与 MIME 相关的 RFC，例如 RFC 2045， RFC 2046， RFC 2047， RFC 2183和 RFC 2231。
电子邮件软件包的整体结构可以分为三个主要部分，以及控制其他部分行为的第四个部分。
软件包的中心组件是代表电子邮件的“对象模型”。应用程序主要passmessage子模块中定义的对象模型接口与程序包进行交互。应用程序可以使用此 API 来询问有关现有电子邮件的问题，构建新电子邮件或添加或删除本身使用相同对象模型接口的电子邮件子组件。也就是说，遵循电子邮件消息及其 MIME 子组件的性质，电子邮件对象模型是所有提供EmailMessage API 的对象的树状结构。
软件包的其他两个主要组成部分是parser和generator。解析器获取电子邮件的序列化版本(字节流)，并将其转换为EmailMessage对象树。生成器获取EmailMessage并将其返回为串行字节流。 (解析器和生成器还处理文本字符流，但是不建议使用此方法，因为这样很容易导致以一种或另一种方式无效的消息结束.)
控制组件是policy模块。每个EmailMessage，每个generator和每个parser都有一个关联的policy对象来控制其行为。通常，应用程序只需要在创建EmailMessage时指定策略，即可直接实例化EmailMessage来创建新电子邮件，也可以使用parser解析 Importing 流。但是，当使用generator序列化消息时，可以更改策略。例如，这允许从磁盘解析通用电子邮件，但在将其发送到电子邮件服务器时使用标准 SMTP 设置对其进行序列化。
电子邮件包会尽力隐藏应用程序中各种 ManagementRFC 的详细信息。从概念上讲，该应用程序应该能够将电子邮件视为 Unicode 文本和二进制附件的结构化树，而不必担心序列化时它们如何表示。但是，实际上，通常有必要至少了解一些控制 MIME 消息及其结构的规则，尤其是 MIME“Content Type”的名称和性质以及它们如何标识 Multipart 文档。在大多数情况下，仅对于更复杂的应用程序才需要此知识，即使如此，它也仅应是有问题的高级结构，而不是如何表示这些结构的详细信息。由于 MIMEContent Type 广泛用于现代 Internet 软件(而不仅仅是电子邮件)中，因此对于许多程序员而言，这将是一个熟悉的概念。
以下各节介绍了email软件包的Function。我们从message对象模型开始，这是应用程序将使用的主要接口，然后是parser和generator组件。然后，我们介绍了policy控件，该控件完成了对该库主要组件的处理。
接下来的三节介绍了程序包可能引发的异常以及parser可能检测到的缺陷(不符合 RFC)。然后，我们介绍了headerregistry和contentmanager子组件，它们分别提供了用于更详细地处理 Headers 和有效负载的工具。这两个组件都包含与使用和生成非平凡消息相关的Function，还记录了它们的可扩展性 API，这将是高级应用程序所感兴趣的。
紧随其后的是使用前面各节介绍的 API 的基本部分的一组示例。
前述内容代表电子邮件包的现代(对 Unicode 友好)的 API。从Message类开始的其余部分，涵盖了旧版compat32 API，该 API 更直接地处理如何表示电子邮件消息的细节。 compat32 API 不会从应用程序中隐藏 RFC 的详细信息，但是对于需要在该级别上运行的应用程序来说，它们可能是有用的工具。该文档还与出于向后兼容性原因而仍在使用compat32 API 的应用程序有关。
在版本 3.6 中进行了更改：重新组织和重写了文档，以推广新的EmailMessage/EmailPolicy API。
email软件包文档的内容：
Legacy API: