email — Электронная почта и пакет обработки MIME

Исходный код: Lib/email/__init__.py

Пакет email представляет собой библиотеку для управления сообщениями электронной почты. Это - конкретно не, разработанный, чтобы сделать любую отправку электронных писем к SMTP (RFC 2821), SMTP или другие серверы; это функции таких модулей, как smtplib и nntplib. Пакет email пытается быть максимально RFC-соответствующим, поддерживая RFC 5233 и RFC 6532, а также такой MIME-связанный RFCs как RFC 2045, RFC 2046, RFC 2047, RFC 2183 и RFC 2231.

Общая структура пакета электронной почты может быть разделена на три основных компонента плюс четвертый компонент, который управляет поведением других компонентов.

Центральным компонентом пакета является объектная модель, представляющая сообщения электронной почты. Приложение взаимодействует с пакетом главным образом через интерфейс объектной модели, определенный в подмодуле message. Приложение может использовать этот API, чтобы задавать вопросы о существующем сообщении электронной почты, создавать новое сообщение электронной почты или добавлять или удалять субкомпоненты электронной почты, которые сами используют тот же интерфейс объектной модели. То есть, следуя характеру сообщений электронной почты и их MIME субкомпонентов, модель объектов электронной почты представляет собой древовидную структуру объектов, которые все предоставляют API EmailMessage.

Двумя другими основными компонентами упаковки являются parser и generator. парсер берет преобразованную в последовательную форму версию электронного письма (поток байтов) и преобразовывает ее в дерево объектов EmailMessage. генератор берет EmailMessage и возвращает его в преобразованный в последовательную форму поток байта. (парсер и генератор также обрабатывают потоки текстовых символов, но это использование не рекомендуется, так как слишком легко получить сообщения, которые так или иначе не являются действительными.

Компонент управления - модуль policy. У каждого EmailMessage, каждого generator и каждого parser есть связанный объект policy, который управляет его поведением. Обычно приложению необходимо указать политику только при создании EmailMessage либо путем непосредственного создания экземпляра EmailMessage для создания нового сообщения электронной почты, либо путем парсинг входного потока с помощью parser. Но политика может быть изменена при сериализации сообщения с помощью generator. Это позволяет, например, анализировать общее сообщение электронной почты с диска, но сериализировать его с помощью стандартных параметров SMTP при отправке на сервер электронной почты.

Пакет электронной почты делает все возможное, чтобы скрыть детали различных управляющих RFC из приложения. Концептуально приложение должно иметь возможность рассматривать сообщение электронной почты как структурированное дерево текста юникода и двоичных вложений, не беспокоясь о том, как они представлены при сериализации. Однако на практике часто необходимо знать, по крайней мере, некоторые правила, регулирующие MIME сообщения и их структуру, в частности названия и характер MIME «типы контента» и то, как они идентифицируют многосерийные документы. По большей части эти знания должны требоваться только для более сложных приложений, и даже в этом случае это должна быть только структура высокого уровня, о которой идет речь, а не детали того, как эти структуры представлены. Так как типы контента MIME - используемый широко в современном интернет-программном обеспечении (не только электронная почта), это будет знакомым понятием многим программистам.

В следующих разделах описываются функциональные возможности пакета email. Мы начинаем с объектной модели message, которая является основным интерфейсом, который будет использоваться приложением, и продолжаем это с компонентами parser и generator. Тогда мы покрываем средства управления policy, который заканчивает обработку главных компонентов библиотеки.

Следующие три раздела охватывают исключения, которые может вызвать упаковка, и дефекты (несоблюдение RFC), которые могут быть обнаружены parser. Затем мы охватываем субкомпоненты headerregistry и contentmanager, которые предоставляют инструменты для более детального манипулирования заголовками и полезной нагрузкой соответственно. Оба этих компонента содержат характеристики, относящиеся к потреблению и производству нетривиальных сообщений, но также документируют их расширяемость API, которая будет представлять интерес для передовых приложений.

Ниже приводится ряд примеров использования основных частей API, описанных в предыдущих разделах.

Вышеизложенное представляет собой современный (удобный для юникода) API пакета электронной почты. Остальные разделы, начиная с класса Message, охватывают устаревший API compat32, который гораздо более непосредственно касается деталей представления сообщений электронной почты. compat32 API делает не, скрывают детали RFC от применения, но для заявлений, которые должны работать на том уровне, они могут быть полезными инструментами. Эта документация также важна для заявлений, которые все еще используют compat32 API по причинам обратной совместимости.

Изменено в версии 3.6: Документы реорганизованы и переписаны для продвижения нового API EmailMessage/EmailPolicy.

Содержание документации пакета email:

Наследуемое API:

См.также

Модуль smtplib
SMTP (Simple Mail Transport Protocol) клиент
Модуль poplib
POP (Post Office Protocol) клиент
Модуль imaplib
IMAP (Internet Message Access Protocol) клиент
Модуль nntplib
NNTP (Net News Transport Protocol)
Модуль mailbox
Инструменты для создания, чтения и управления коллекциями сообщений на диске с использованием различных стандартных форматов.
Модуль smtpd
SMTP-сервер фреймворк (в первую очередь полезен для тестирования)