1 % Copyright (C) 2001-2004 Python Software Foundation
2 % Author: barry@python.org (Barry Warsaw)
4 \section{\module{email
} ---
5 An email and MIME handling package
}
7 \declaremodule{standard
}{email
}
8 \modulesynopsis{Package supporting the parsing, manipulating, and
9 generating email messages, including MIME documents.
}
10 \moduleauthor{Barry A. Warsaw
}{barry@python.org
}
11 \sectionauthor{Barry A. Warsaw
}{barry@python.org
}
15 The
\module{email
} package is a library for managing email messages,
16 including MIME and other
\rfc{2822}-based message documents. It
17 subsumes most of the functionality in several older standard modules
18 such as
\refmodule{rfc822
},
\refmodule{mimetools
},
19 \refmodule{multifile
}, and other non-standard packages such as
20 \module{mimecntl
}. It is specifically
\emph{not
} designed to do any
21 sending of email messages to SMTP (
\rfc{2821}) servers; that is the
22 function of the
\refmodule{smtplib
} module. The
\module{email
}
23 package attempts to be as RFC-compliant as possible, supporting in
24 addition to
\rfc{2822}, such MIME-related RFCs as
25 \rfc{2045},
\rfc{2046},
\rfc{2047}, and
\rfc{2231}.
27 The primary distinguishing feature of the
\module{email
} package is
28 that it splits the parsing and generating of email messages from the
29 internal
\emph{object model
} representation of email. Applications
30 using the
\module{email
} package deal primarily with objects; you can
31 add sub-objects to messages, remove sub-objects from messages,
32 completely re-arrange the contents, etc. There is a separate parser
33 and a separate generator which handles the transformation from flat
34 text to the object model, and then back to flat text again. There
35 are also handy subclasses for some common MIME object types, and a few
36 miscellaneous utilities that help with such common tasks as extracting
37 and parsing message field values, creating RFC-compliant dates, etc.
39 The following sections describe the functionality of the
40 \module{email
} package. The ordering follows a progression that
41 should be common in applications: an email message is read as flat
42 text from a file or other source, the text is parsed to produce the
43 object structure of the email message, this structure is manipulated,
44 and finally rendered back into flat text.
46 It is perfectly feasible to create the object structure out of whole
47 cloth --- i.e. completely from scratch. From there, a similar
48 progression can be taken as above.
50 Also included are detailed specifications of all the classes and
51 modules that the
\module{email
} package provides, the exception
52 classes you might encounter while using the
\module{email
} package,
53 some auxiliary utilities, and a few examples. For users of the older
54 \module{mimelib
} package, or previous versions of the
\module{email
}
55 package, a section on differences and porting is provided.
58 \seemodule{smtplib
}{SMTP protocol client
}
61 \subsection{Representing an email message
}
64 \subsection{Parsing email messages
}
67 \subsection{Generating MIME documents
}
68 \input{emailgenerator
}
70 \subsection{Creating email and MIME objects from scratch
}
73 \subsection{Internationalized headers
}
76 \subsection{Representing character sets
}
82 \subsection{Exception and Defect classes
}
85 \subsection{Miscellaneous utilities
}
88 \subsection{Iterators
}
91 \subsection{Package History
}
93 Version
1 of the
\module{email
} package was bundled with Python
94 releases up to Python
2.2.1. Version
2 was developed for the Python
95 2.3 release, and backported to Python
2.2.2. It was also available as
96 a separate distutils-based package, and is compatible back to Python
2.1.
98 \module{email
} version
3.0 was released with Python
2.4 and as a separate
99 distutils-based package. It is compatible back to Python
2.3.
101 Here are the differences between
\module{email
} version
3 and version
2:
104 \item The
\class{FeedParser
} class was introduced, and the
\class{Parser
}
105 class was implemented in terms of the
\class{FeedParser
}. All parsing
106 there for is non-strict, and parsing will make a best effort never to
107 raise an exception. Problems found while parsing messages are stored in
108 the message's
\var{defect
} attribute.
110 \item All aspects of the API which raised
\exception{DeprecationWarning
}s in
111 version
2 have been removed. These include the
\var{_encoder
} argument
112 to the
\class{MIMEText
} constructor, the
\method{Message.add_payload()
}
113 method, the
\function{Utils.dump_address_pair()
} function, and the
114 functions
\function{Utils.decode()
} and
\function{Utils.encode()
}.
116 \item New
\exception{DeprecationWarning
}s have been added to:
117 \method{Generator.__call__()
},
\method{Message.get_type()
},
118 \method{Message.get_main_type()
},
\method{Message.get_subtype()
}, and
119 the
\var{strict
} argument to the
\class{Parser
} class. These are
120 expected to be removed in email
3.1.
122 \item Support for Pythons earlier than
2.3 has been removed.
125 Here are the differences between
\module{email
} version
2 and version
1:
128 \item The
\module{email.Header
} and
\module{email.Charset
} modules
131 \item The pickle format for
\class{Message
} instances has changed.
132 Since this was never (and still isn't) formally defined, this
133 isn't considered a backward incompatibility. However if your
134 application pickles and unpickles
\class{Message
} instances, be
135 aware that in
\module{email
} version
2,
\class{Message
}
136 instances now have private variables
\var{_charset
} and
139 \item Several methods in the
\class{Message
} class have been
140 deprecated, or their signatures changed. Also, many new methods
141 have been added. See the documentation for the
\class{Message
}
142 class for details. The changes should be completely backward
145 \item The object structure has changed in the face of
146 \mimetype{message/rfc822
} content types. In
\module{email
}
147 version
1, such a type would be represented by a scalar payload,
148 i.e. the container message's
\method{is_multipart()
} returned
149 false,
\method{get_payload()
} was not a list object, but a single
150 \class{Message
} instance.
152 This structure was inconsistent with the rest of the package, so
153 the object representation for
\mimetype{message/rfc822
} content
154 types was changed. In
\module{email
} version
2, the container
155 \emph{does
} return
\code{True
} from
\method{is_multipart()
}, and
156 \method{get_payload()
} returns a list containing a single
157 \class{Message
} item.
159 Note that this is one place that backward compatibility could
160 not be completely maintained. However, if you're already
161 testing the return type of
\method{get_payload()
}, you should be
162 fine. You just need to make sure your code doesn't do a
163 \method{set_payload()
} with a
\class{Message
} instance on a
164 container with a content type of
\mimetype{message/rfc822
}.
166 \item The
\class{Parser
} constructor's
\var{strict
} argument was
167 added, and its
\method{parse()
} and
\method{parsestr()
} methods
168 grew a
\var{headersonly
} argument. The
\var{strict
} flag was
169 also added to functions
\function{email.message_from_file()
}
170 and
\function{email.message_from_string()
}.
172 \item \method{Generator.__call__()
} is deprecated; use
173 \method{Generator.flatten()
} instead. The
\class{Generator
}
174 class has also grown the
\method{clone()
} method.
176 \item The
\class{DecodedGenerator
} class in the
177 \module{email.Generator
} module was added.
179 \item The intermediate base classes
\class{MIMENonMultipart
} and
180 \class{MIMEMultipart
} have been added, and interposed in the
181 class hierarchy for most of the other MIME-related derived
184 \item The
\var{_encoder
} argument to the
\class{MIMEText
} constructor
185 has been deprecated. Encoding now happens implicitly based
186 on the
\var{_charset
} argument.
188 \item The following functions in the
\module{email.Utils
} module have
189 been deprecated:
\function{dump_address_pairs()
},
190 \function{decode()
}, and
\function{encode()
}. The following
191 functions have been added to the module:
192 \function{make_msgid()
},
\function{decode_rfc2231()
},
193 \function{encode_rfc2231()
}, and
\function{decode_params()
}.
195 \item The non-public function
\function{email.Iterators._structure()
}
199 \subsection{Differences from
\module{mimelib
}}
201 The
\module{email
} package was originally prototyped as a separate
203 \ulink{\module{mimelib
}}{http://mimelib.sf.net/
}.
204 Changes have been made so that
205 method names are more consistent, and some methods or modules have
206 either been added or removed. The semantics of some of the methods
207 have also changed. For the most part, any functionality available in
208 \module{mimelib
} is still available in the
\refmodule{email
} package,
209 albeit often in a different way. Backward compatibility between
210 the
\module{mimelib
} package and the
\module{email
} package was not a
213 Here is a brief description of the differences between the
214 \module{mimelib
} and the
\refmodule{email
} packages, along with hints on
215 how to port your applications.
217 Of course, the most visible difference between the two packages is
218 that the package name has been changed to
\refmodule{email
}. In
219 addition, the top-level package has the following differences:
222 \item \function{messageFromString()
} has been renamed to
223 \function{message_from_string()
}.
225 \item \function{messageFromFile()
} has been renamed to
226 \function{message_from_file()
}.
230 The
\class{Message
} class has the following differences:
233 \item The method
\method{asString()
} was renamed to
\method{as_string()
}.
235 \item The method
\method{ismultipart()
} was renamed to
236 \method{is_multipart()
}.
238 \item The
\method{get_payload()
} method has grown a
\var{decode
}
241 \item The method
\method{getall()
} was renamed to
\method{get_all()
}.
243 \item The method
\method{addheader()
} was renamed to
\method{add_header()
}.
245 \item The method
\method{gettype()
} was renamed to
\method{get_type()
}.
247 \item The method
\method{getmaintype()
} was renamed to
248 \method{get_main_type()
}.
250 \item The method
\method{getsubtype()
} was renamed to
251 \method{get_subtype()
}.
253 \item The method
\method{getparams()
} was renamed to
254 \method{get_params()
}.
255 Also, whereas
\method{getparams()
} returned a list of strings,
256 \method{get_params()
} returns a list of
2-tuples, effectively
257 the key/value pairs of the parameters, split on the
\character{=
}
260 \item The method
\method{getparam()
} was renamed to
\method{get_param()
}.
262 \item The method
\method{getcharsets()
} was renamed to
263 \method{get_charsets()
}.
265 \item The method
\method{getfilename()
} was renamed to
266 \method{get_filename()
}.
268 \item The method
\method{getboundary()
} was renamed to
269 \method{get_boundary()
}.
271 \item The method
\method{setboundary()
} was renamed to
272 \method{set_boundary()
}.
274 \item The method
\method{getdecodedpayload()
} was removed. To get
275 similar functionality, pass the value
1 to the
\var{decode
} flag
276 of the
{get_payload()
} method.
278 \item The method
\method{getpayloadastext()
} was removed. Similar
280 is supported by the
\class{DecodedGenerator
} class in the
281 \refmodule{email.Generator
} module.
283 \item The method
\method{getbodyastext()
} was removed. You can get
284 similar functionality by creating an iterator with
285 \function{typed_subpart_iterator()
} in the
286 \refmodule{email.Iterators
} module.
289 The
\class{Parser
} class has no differences in its public interface.
290 It does have some additional smarts to recognize
291 \mimetype{message/delivery-status
} type messages, which it represents as
292 a
\class{Message
} instance containing separate
\class{Message
}
293 subparts for each header block in the delivery status
294 notification
\footnote{Delivery Status Notifications (DSN) are defined
297 The
\class{Generator
} class has no differences in its public
298 interface. There is a new class in the
\refmodule{email.Generator
}
299 module though, called
\class{DecodedGenerator
} which provides most of
300 the functionality previously available in the
301 \method{Message.getpayloadastext()
} method.
303 The following modules and classes have been changed:
306 \item The
\class{MIMEBase
} class constructor arguments
\var{_major
}
307 and
\var{_minor
} have changed to
\var{_maintype
} and
308 \var{_subtype
} respectively.
310 \item The
\code{Image
} class/module has been renamed to
311 \code{MIMEImage
}. The
\var{_minor
} argument has been renamed to
314 \item The
\code{Text
} class/module has been renamed to
315 \code{MIMEText
}. The
\var{_minor
} argument has been renamed to
318 \item The
\code{MessageRFC822
} class/module has been renamed to
319 \code{MIMEMessage
}. Note that an earlier version of
320 \module{mimelib
} called this class/module
\code{RFC822
}, but
321 that clashed with the Python standard library module
322 \refmodule{rfc822
} on some case-insensitive file systems.
324 Also, the
\class{MIMEMessage
} class now represents any kind of
325 MIME message with main type
\mimetype{message
}. It takes an
326 optional argument
\var{_subtype
} which is used to set the MIME
327 subtype.
\var{_subtype
} defaults to
\mimetype{rfc822
}.
330 \module{mimelib
} provided some utility functions in its
331 \module{address
} and
\module{date
} modules. All of these functions
332 have been moved to the
\refmodule{email.Utils
} module.
334 The
\code{MsgReader
} class/module has been removed. Its functionality
335 is most closely supported in the
\function{body_line_iterator()
}
336 function in the
\refmodule{email.Iterators
} module.
338 \subsection{Examples
}
340 Here are a few examples of how to use the
\module{email
} package to
341 read, write, and send simple email messages, as well as more complex
344 First, let's see how to create and send a simple text message:
346 \verbatiminput{email-simple.py
}
348 Here's an example of how to send a MIME message containing a bunch of
349 family pictures that may be residing in a directory:
351 \verbatiminput{email-mime.py
}
353 Here's an example of how to send the entire contents of a directory as
355 \footnote{Thanks to Matthew Dixon Cowles for the original inspiration
358 \verbatiminput{email-dir.py
}
360 And finally, here's an example of how to unpack a MIME message like
361 the one above, into a directory of files:
363 \verbatiminput{email-unpack.py
}
