Skip to content

Latest commit

 

History

History
390 lines (297 loc) · 17.8 KB

email.rst

File metadata and controls

390 lines (297 loc) · 17.8 KB
Raw

:mod:`email` --- An email and MIME handling package

.. module:: email
   :synopsis: Package supporting the parsing, manipulating, and generating
              email messages, including MIME documents.


.. moduleauthor:: Barry A. Warsaw <barry@python.org>

.. sectionauthor:: Barry A. Warsaw <barry@python.org>

Source code: :source:`Lib/email/__init__.py`

The :mod:`email` package is a library for managing email messages, including MIME and other RFC 2822-based message documents. It is specifically not designed to do any sending of email messages to SMTP (RFC 2821), NNTP, or other servers; those are functions of modules such as :mod:`smtplib` and :mod:`nntplib`. The :mod:`email` package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231.

The primary distinguishing feature of the :mod:`email` package is that it splits the parsing and generating of email messages from the internal object model representation of email. Applications using the :mod:`email` package deal primarily with objects; you can add sub-objects to messages, remove sub-objects from messages, completely re-arrange the contents, etc. There is a separate parser and a separate generator which handles the transformation from flat text to the object model, and then back to flat text again. There are also handy subclasses for some common MIME object types, and a few miscellaneous utilities that help with such common tasks as extracting and parsing message field values, creating RFC-compliant dates, etc.

The following sections describe the functionality of the :mod:`email` package. The ordering follows a progression that should be common in applications: an email message is read as flat text from a file or other source, the text is parsed to produce the object structure of the email message, this structure is manipulated, and finally, the object tree is rendered back into flat text.

It is perfectly feasible to create the object structure out of whole cloth --- i.e. completely from scratch. From there, a similar progression can be taken as above.

Also included are detailed specifications of all the classes and modules that the :mod:`email` package provides, the exception classes you might encounter while using the :mod:`email` package, some auxiliary utilities, and a few examples. For users of the older :mod:`mimelib` package, or previous versions of the :mod:`email` package, a section on differences and porting is provided.

Contents of the :mod:`email` package documentation:

.. toctree::

   email.message.rst
   email.parser.rst
   email.generator.rst
   email.policy.rst
   email.headerregistry.rst
   email.contentmanager.rst
   email.mime.rst
   email.header.rst
   email.charset.rst
   email.encoders.rst
   email.errors.rst
   email.util.rst
   email.iterators.rst
   email-examples.rst



.. seealso::

   Module :mod:`smtplib`
      SMTP protocol client

   Module :mod:`nntplib`
      NNTP protocol client

Package History

This table describes the release history of the email package, corresponding to the version of Python that the package was released with. For purposes of this document, when you see a note about change or added versions, these refer to the Python version the change was made in, not the email package version. This table also describes the Python compatibility of each version of the package.

email version distributed with compatible with
:const:`1.x` Python 2.2.0 to Python 2.2.1 no longer supported
:const:`2.5` Python 2.2.2+ and Python 2.3 Python 2.1 to 2.5
:const:`3.0` Python 2.4 and Python 2.5 Python 2.3 to 2.6
:const:`4.0` Python 2.5 to Python 2.7 Python 2.3 to 2.7
:const:`5.0` Python 3.0 and Python 3.1 Python 3.0 to 3.2
:const:`5.1` Python 3.2 Python 3.2

After Version 5.1 (Python 3.2), the email package no longer has a version that is separate from the Python version. (See the :ref:`whatsnew-index` documents for the respective Python versions for details on changes.)

Here are the major differences between :mod:`email` version 5.1 and version 5.0:

Here are the major differences between :mod:`email` version 5.0 and version 4:

  • All operations are on unicode strings. Text inputs must be strings, text outputs are strings. Outputs are limited to the ASCII character set and so can be encoded to ASCII for transmission. Inputs are also limited to ASCII; this is an acknowledged limitation of email 5.0 and means it can only be used to parse email that is 7bit clean.

Here are the major differences between :mod:`email` version 4 and version 3:

Here are the major differences between :mod:`email` version 3 and version 2:

Here are the differences between :mod:`email` version 2 and version 1:

Differences from :mod:`mimelib`

The :mod:`email` package was originally prototyped as a separate library called mimelib. Changes have been made so that method names are more consistent, and some methods or modules have either been added or removed. The semantics of some of the methods have also changed. For the most part, any functionality available in :mod:`mimelib` is still available in the :mod:`email` package, albeit often in a different way. Backward compatibility between the :mod:`mimelib` package and the :mod:`email` package was not a priority.

Here is a brief description of the differences between the :mod:`mimelib` and the :mod:`email` packages, along with hints on how to port your applications.

Of course, the most visible difference between the two packages is that the package name has been changed to :mod:`email`. In addition, the top-level package has the following differences:

The :class:`~email.message.Message` class has the following differences:

The :class:`~email.parser.Parser` class has no differences in its public interface. It does have some additional smarts to recognize :mimetype:`message/delivery-status` type messages, which it represents as a :class:`~email.message.Message` instance containing separate :class:`~email.message.Message` subparts for each header block in the delivery status notification [1].

The :class:`~email.generator.Generator` class has no differences in its public interface. There is a new class in the :mod:`email.generator` module though, called :class:`~email.generator.DecodedGenerator` which provides most of the functionality previously available in the :meth:`Message.getpayloadastext` method.

The following modules and classes have been changed:

  • The :class:`~email.mime.base.MIMEBase` class constructor arguments _major and _minor have changed to _maintype and _subtype respectively.

  • The Image class/module has been renamed to MIMEImage. The _minor argument has been renamed to _subtype.

  • The Text class/module has been renamed to MIMEText. The _minor argument has been renamed to _subtype.

  • The MessageRFC822 class/module has been renamed to MIMEMessage. Note that an earlier version of :mod:`mimelib` called this class/module RFC822, but that clashed with the Python standard library module :mod:`rfc822` on some case-insensitive file systems.

    Also, the :class:`~email.mime.message.MIMEMessage` class now represents any kind of MIME message with main type :mimetype:`message`. It takes an optional argument _subtype which is used to set the MIME subtype. _subtype defaults to :mimetype:`rfc822`.

:mod:`mimelib` provided some utility functions in its :mod:`address` and :mod:`date` modules. All of these functions have been moved to the :mod:`email.utils` module.

The MsgReader class/module has been removed. Its functionality is most closely supported in the :func:`~email.iterators.body_line_iterator` function in the :mod:`email.iterators` module.

Footnotes

[1]Delivery Status Notifications (DSN) are defined in RFC 1894.