"Lepaquet :mod:`email` est unebibliothèque pour gérer lesemails. Il n'est spécifiquement *pas* conçu pour faire desenvois d'emails vers SMTP (:rfc:`2821), NNTP, ou autres serveurs; ce sont desfonctions demodules comme :mod:`smtplib` and :mod:`nntplib`. Lepaquet :mod:`email` tente derespecter lesRFC autant que possible, supportant :rfc:`5233` et :rfc:`6532`, ainsi que lesRFCs en rapport avec les MIME comme :rfc:`2045`, :rfc:`2046`, :rfc:`2047`, :rfc:`2183`, et :rfc:`2231`."
"Le composant central du paquet est un \"modèle d'objet\" qui représente les messages. Une application intéragit avec le paquet, dans un premier temps, à travers l'interface de modèle d'objet définie dans le sous-module :mod:`~email.message`. L'application peut utiliser cette API pour poser des questions à propos d'un mail existant, pour créer un nouvel email, ou ajouter ou retirer des sous-composants d'email 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'email est une structure en arborescence d'objets qui fournit tout à l'API de :class:`~email.message.EmailMessage`."
"Les deux autres composants majeurs de ce paquet sont l'analyseur(:mod:`~email.parser`) et le generateur(:mod:`~email.generator`). L'analyseur prends la version sérializée d'un email (un flux d'octets) et le convertit en une arborescence d'objets :class:`~email.message.EmailMessage`. Le générateur prends un object :class:`~email.message.EmailMessage` et le retransforme en un flux d'octets sérializée. (L'analyseur et le générateur gère 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 :mod:`~email.policy`. chaque :class:`~email.message.EmailMessage`, chaque :mod:`~email.generator`, et chaque :mod:`~email.parser` possède un objet associé :mod:`~email.policy` qui contrôle son comportement. Habituellement une application n'a besoin de spécifier la politique que quand un :class:`~email.message.EmailMessage` est créé, soit en instanciant directement un :class:`~email.message.EmailMessage` pour créer un nouvel email, ou en analysant un flux entrant en utilisant un :mod:`~email.parser`. Mais la politique peut être changée quand le message est serializé en utilisant un :mod:`~email.generator`. Cela permet, par exemple, d'analyser un message email générique du disque, mais de le sérializer en utilisant les réglages SMTP standarts SMTP quand envoyés vers un serveur d'email."
"Le packet email fait son maximum pour cacher les détails des différents RFCs gouvernants de l'application. Conceptuellement, l'application devrait être capable de traiter l'email comme une arborescence structurée de texte unicode et de pièces jointes binaires, sans avoir à se préoccuper de leur réprensation sérializée. Dans la pratique, cependant, il est souvent nécessaire d'être conscient d'au moins quelques règles gouvernant les messages MIME et leurs structures, 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. Vu que les types de contenus MIME sont couramment utilisés dans les logiciels internet modernes(et non uniquement les emails), ce sera un concept familier à de multiples programmeurs."
"La section suivante décrit les fonctionnalités du paquet :mod:`email`. Nous commençons avec le modèle d'objet :mod:`~email.message`, qui est la principale interface qu'une application utilisera, et continueront avec les composants :mod:`~email.parser` et :mod:`~email.generator`. Ensuite, nous couvrirons les contrôles :mod:`~email.policy`, qui complètent le traitement des principaux composants de la librairie."
"Les trois prochaines sections couvrent les exceptions que le paquet peut rencontrer et les imperfections (non-respect des RFCs) que l':mod:`~email.parser` pourrait détecter. Ensuite nous couvrons les sous-composants :mod:`~email.headerregistry` et :mod:`~email.contentmanager`, qui fournissent des outils pour faire des manipulations plus détaillées des en-têtes et puissances, respectivement. Les deux composants contiennent des fonctionnalités pertinentes pour traiter et produire des messages qui sortent de l'ordinaire, mais aussi documenter leurs APIs d'extensibilité, ce qui se montrera d'un grand intérêt pour les applications avancées "
"L'élément précédent représente l'API moderne (tolérant l'unicode) du packet email. Les sections restantes, commençant par la classe :class:`~email.message.Message`, couvrent l'API héritée :data:`~email.policy.compat32` qui traite beaucoup plus directement des détails sur la manière dont les emails sont representés. L'API :data:`~email.policy.compat32` ne cache *pas* les détails des RFCs de l'application, mais pour les applications qui requièrent d'opérer à ce niveau, elle peut être un outil pratique. Cette documentation est aussi pertinante pour les applications qui utilisent toujours l'API :mod:`~email.policy.compat32` pour des raisons de rétrocompatibilité."
