19.1. email — Un paquet de gestion des e-mails et MIME

Code source: Lib/email/__init__.py

Le paquet email est une bibliothèque pour gérer les e-mails. Il est spécifiquement conçu pour ne pas gérer les envois d’e-mails vers SMTP (RFC 2821), NNTP, ou autres serveurs ; ces fonctions sont du ressort des modules comme smtplib et nntplib. Le paquet email tente de respecter les RFC autant que possible, il gère RFC 5233 et RFC 6532, ainsi que les RFCs en rapport avec les MIME comme RFC 2045, RFC 2046, RFC 2047, RFC 2183, et RFC 2231.

Ce paquet peut être divisé entre trois composants majeurs, et un quatrième composant qui contrôle le comportement des trois autres.

Le composant central du paquet est un « modèle d’objet » qui représente les messages. Une application interagit avec le paquet, dans un premier temps, à travers l’interface de modèle d’objet définie dans le sous-module message. L’application peut utiliser cette API pour poser des questions à propos d’un mail existant, pour créer un nouvel e-mail, ou ajouter ou retirer des sous-composants d’e-mail qui utilisent la même interface de modèle d’objet. Suivant la nature des messages et leurs sous-composants MIME, le modèle d’objet d’e-mail est une structure arborescente d’objets qui fournit tout à l’API de EmailMessage.

Les deux autres composants majeurs de ce paquet sont l’analyseur (parser) et le générateur (generator). L’analyseur prend la version sérialisée d’un e-mail (un flux d’octets) et le convertit en une arborescence d’objets EmailMessage. Le générateur prend un objet EmailMessage et le retransforme en un flux d’octets sérialisé (l’analyseur et le générateur gèrent aussi des suites de caractères textuels, mais cette utilisation est déconseillée car il est très facile de finir avec des messages invalides d’une manière ou d’une autre).

Le composant de contrôle est le module policy. Chaque EmailMessage, chaque generator et chaque parser possède un objet associé policy qui contrôle son comportement. Habituellement une application n’a besoin de spécifier la politique que quand un EmailMessage est créé, soit en instanciant directement un EmailMessage pour créer un nouvel e-mail, soit lors de l’analyse d’un flux entrant en utilisant un parser. Mais la politique peut être changée quand le message est sérialisé en utilisant un generator. Cela permet, par exemple, d’analyser un message e-mail générique du disque, puis de le sérialiser en utilisant une configuration SMTP standard quand on l’envoie vers un serveur d’e-mail.

Le paquet email fait son maximum pour cacher les détails des différentes RFCs de référence à l’application. Conceptuellement, l’application doit être capable de traiter l’e-mail comme une arborescence structurée de texte Unicode et de pièces jointes binaires, sans avoir à se préoccuper de leur représentation sérialisée. Dans la pratique, cependant, il est souvent nécessaire d’être conscient d’au moins quelques règles relatives aux messages MIME et à leur structure, en particulier les noms et natures des « types de contenus » et comment ils identifient les documents à plusieurs parties. Pour la plupart, cette connaissance devrait seulement être nécessaire pour des applications plus complexes, et même là, il devrait être question des structures de haut niveau et non des détails sur la manière dont elles sont représentées. Comme les types de contenus MIME sont couramment utilisés dans les logiciels internet modernes (et non uniquement les e-mails), les développeurs sont généralement familiers de ce concept.

La section suivante décrit les fonctionnalités du paquet email. Nous commençons avec le modèle d’objet message, qui est la principale interface qu’une application utilise, et continuons avec les composants parser et generator. Ensuite, nous couvrons les contrôles policy, qui complètent le traitement des principaux composants de la bibliothèque.

Les trois prochaines sections couvrent les exceptions que le paquet peut rencontrer et les imperfections (non-respect des RFCs) que le module parser peut détecter. Ensuite nous couvrons les sous-composants headerregistry et contentmanager, qui fournissent des outils pour faire des manipulations plus détaillées des en-têtes et du contenu, respectivement. Les deux composants contiennent des fonctionnalités adaptées pour traiter et produire des messages qui sortent de l’ordinaire, et elles documentent aussi leurs API pour pouvoir les étendre, ce qui ne manquera pas d’intéresser les applications avancées.

Ci-dessous se trouve un ensemble d’exemples d’utilisations des éléments fondamentaux des API couvertes dans les sections précédentes.

The foregoing represent the modern (unicode friendly) API of the email package. The remaining sections, starting with the Message class, cover the legacy compat32 API that deals much more directly with the details of how email messages are represented. The compat32 API does not hide the details of the RFCs from the application, but for applications that need to operate at that level, they can be useful tools. This documentation is also relevant for applications that are still using the compat32 API for backward compatibility reasons.

Modifié dans la version 3.6: Documents réorganisés et réécrits pour promouvoir la nouvelle API EmailMessage/EmailPolicy.

Contenus de la documentation du paquet email :

API héritée :

Voir aussi

Module smtplib

Client SMTP (Simple Mail Transport Protocol)

Module poplib

Client POP (Post Office Protocol)

Module imaplib

Client IMAP (Internet Message Access Protocol)

Module nntplib

Client NNTP (Net News Transport Protocol)

Module mailbox

Outils pour créer, lire et gérer des messages regroupés sur disque en utilisant des formats standards variés.

Module smtpd

Cadriciel pour serveur SMTP (principalement utile pour tester)