Skip to main content

19.1. email —电子邮件和MIME处理包

源代码: Lib/email/__init__.py


email 包是用于管理电子邮件的库。它专门用于执行任何发送电子邮件到SMTP(RFC 2821),NNTP或其他服务器的 not;那些是诸如 smtplibnntplib 的模块的功能。 email 包试图尽可能地符合RFC,支持 RFC 5233RFC 6532,以及诸如 RFC 2045RFC 2046RFC 2047RFC 2183RFC 2231 之类的与MIME相关的RFC。

电子邮件包的总体结构可以分为三个主要组件,以及控制其他组件行为的第四个组件。

包的中心组件是表示电子邮件消息的“对象模型”。应用程序主要通过 message 子模块中定义的对象模型接口与包交互。应用程序可以使用此API提出有关现有电子邮件的问题,构建新电子邮件,或添加或删除自身使用相同对象模型界面的电子邮件子组件。也就是说,根据电子邮件消息及其MIME子组件的性质,电子邮件对象模型是所有提供 EmailMessage API的对象的树结构。

包的其他两个主要组件是 parsergenerator。解析器获取电子邮件消息(字节流)的序列化版本,并将其转换为 EmailMessage 对象的树。生成器采用 EmailMessage 并将其转换回串行化的字节流。 (解析器和生成器也处理文本字符流,但是这种用法是不鼓励的,因为它太容易结束与在一种或另一种方式无效的消息)。

控制组件是 policy 模块。每个 EmailMessage,每个 generator 和每个 parser 具有控制其行为的关联 policy 对象。通常,应用程序只需要在创建 EmailMessage 时指定策略,或者通过直接实例化 EmailMessage 来创建新的电子邮件,或者通过使用 parser 解析输入流。但是当使用 generator 对消息进行序列化时,可以更改策略。这允许例如从磁盘解析通用电子邮件消息,但是当将其发送到电子邮件服务器时使用标准SMTP设置将其序列化。

电子邮件包最好从应用程序中隐藏各种管理RFC的详细信息。在概念上,应用程序应该能够将电子邮件作为unicode文本和二进制附件的结构树,而不必担心在序列化时如何表示。然而,在实践中,通常需要知道至少一些管理MIME消息的规则及其结构,特别是MIME“内容类型”的名称和性质以及它们如何识别多部分文档。在大多数情况下,这种知识只应用于更复杂的应用程序,即使那样,它只应该是所讨论的高级结构,而不是如何表示这些结构的细节。由于MIME内容类型在现代互联网软件(而不仅仅是电子邮件)中广泛使用,对许多程序员而言,这将是一个常见的概念。

以下部分描述了 email 软件包的功能。我们从 message 对象模型开始,这是应用程序将使用的主要接口,然后跟随 parsergenerator 组件。然后我们覆盖了 policy 控件,这完成了对库的主要组件的处理。

接下来的三个部分涵盖了包可能引发的例外和 parser 可能检测到的缺陷(不符合RFC)。然后,我们涵盖 headerregistrycontentmanager 子组件,它们分别提供用于更详细地操作报头和有效载荷的工具。这两个组件包含与消费和生成非平凡消息相关的特征,但也记录了它们的可扩展性API,这将是高级应用感兴趣的。

以下是一些使用前面章节中介绍的API的基本部分的示例。

上述代表了电子邮件包的现代(unicode友好)API。其余部分,从 Message 类开始,涵盖了传统的 compat32 API,其更直接地处理电子邮件消息的表示细节。 compat32 API确实 not 从应用程序中隐藏了RFC的详细信息,但是对于需要在该级别操作的应用程序,它们可以是有用的工具。由于向后兼容性原因,此文档还与仍在使用 compat32 API的应用程序相关。

在 3.6 版更改: 文档重组和重写以促进新的 EmailMessage/EmailPolicy API。

email 软件包文档的内容:

旧版API:

参见

模块 smtplib

SMTP(简单邮件传输协议)客户端

模块 poplib

POP(邮局协议)客户端

模块 imaplib

IMAP(因特网消息访问协议)客户端

模块 nntplib

NNTP(网络新闻传输协议)客户端

模块 mailbox

用于使用各种标准格式创建,读取和管理磁盘上的消息集合的工具。

模块 smtpd

SMTP服务器框架(主要用于测试)