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