Updates do email package documentation for markup, style, and
organization.
diff --git a/Doc/lib/email.tex b/Doc/lib/email.tex
index 4d955cc..afa13ff 100644
--- a/Doc/lib/email.tex
+++ b/Doc/lib/email.tex
@@ -14,8 +14,9 @@
 The \module{email} package is a library for managing email messages,
 including MIME and other \rfc{2822}-based message documents.  It
 subsumes most of the functionality in several older standard modules
-such as \module{rfc822}, \module{mimetools}, \module{multifile}, and
-other non-standard packages such as \module{mimecntl}.
+such as \refmodule{rfc822}, \refmodule{mimetools},
+\refmodule{multifile}, and other non-standard packages such as
+\module{mimecntl}.
 
 The primary distinguishing feature of the \module{email} package is
 that it splits the parsing and generating of email messages from the
@@ -38,8 +39,8 @@
 flat text.
 
 It is perfectly feasible to create the object model out of whole cloth
--- i.e. completely from scratch.  From there, a similar progression can
-be taken as above.  
+--- 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 \module{email} package provides, the exception
@@ -49,76 +50,13 @@
 descendent, a section on differences and porting is provided.
 
 \subsection{Representing an email message}
-
-The primary object in the \module{email} package is the
-\class{Message} class, provided in the \refmodule{email.Message}
-module.  \class{Message} is the base class for the \module{email}
-object model.  It provides the core functionality for setting and
-querying header fields, and for accessing message bodies.
-
-Conceptually, a \class{Message} object consists of \emph{headers} and
-\emph{payloads}.  Headers are \rfc{2822} style field name and
-values where the field name and value are separated by a colon.  The
-colon is not part of either the field name or the field value.
-
-Headers are stored and returned in case-preserving form but are
-matched case-insensitively.  There may also be a single
-\emph{Unix-From} header, also known as the envelope header or the
-\mailheader{From_} header.  The payload is either a string in the case of
-simple message objects, a list of \class{Message} objects for
-multipart MIME documents, or a single \class{Message} instance for
-\mimetype{message/rfc822} type objects.
-
-\class{Message} objects provide a mapping style interface for
-accessing the message headers, and an explicit interface for accessing
-both the headers and the payload.  It provides convenience methods for
-generating a flat text representation of the message object tree, for
-accessing commonly used header parameters, and for recursively walking
-over the object tree.
+\input{emailmessage}
 
 \subsection{Parsing email messages}
-Message object trees can be created in one of two ways: they can be
-created from whole cloth by instantiating \class{Message} objects and
-stringing them together via \method{add_payload()} and
-\method{set_payload()} calls, or they can be created by parsing a flat text
-representation of the email message.
-
-The \module{email} package provides a standard parser that understands
-most email document structures, including MIME documents.  You can
-pass the parser a string or a file object, and the parser will return
-to you the root \class{Message} instance of the object tree.  For
-simple, non-MIME messages the payload of this root object will likely
-be a string (e.g. containing the text of the message).  For MIME
-messages, the root object will return 1 from its
-\method{is_multipart()} method, and the subparts can be accessed via
-the \method{get_payload()} and \method{walk()} methods.
-
-Note that the parser can be extended in limited ways, and of course
-you can implement your own parser completely from scratch.  There is
-no magical connection between the \module{email} package's bundled
-parser and the
-\class{Message} class, so your custom parser can create message object
-trees in any way it find necessary.  The \module{email} package's
-parser is described in detail in the \refmodule{email.Parser} module
-documentation.
+\input{emailparser}
 
 \subsection{Generating MIME documents}
-One of the most common tasks is to generate the flat text of the email
-message represented by a message object tree.  You will need to do
-this if you want to send your message via the \refmodule{smtplib}
-module or the \refmodule{nntplib} module, or print the message on the
-console.  Taking a message object tree and producing a flat text
-document is the job of the \refmodule{email.Generator} module.
-
-Again, as with the \refmodule{email.Parser} module, you aren't limited
-to the functionality of the bundled generator; you could write one
-from scratch yourself.  However the bundled generator knows how to
-generate most email in a standards-compliant way, should handle MIME
-and non-MIME email messages just fine, and is designed so that the
-transformation from flat text, to an object tree via the
-\class{Parser} class,
-and back to flat text, be idempotent (the input is identical to the
-output).
+\input{emailgenerator}
 
 \subsection{Creating email and MIME objects from scratch}
 
@@ -156,9 +94,10 @@
 primarily as a convenient base class for more specific MIME-aware
 subclasses.
 
-\var{_maintype} is the \code{Content-Type:} major type (e.g. \code{text} or
-\code{image}), and \var{_subtype} is the \code{Content-Type:} minor type
-(e.g. \code{plain} or \code{gif}).  \var{_params} is a parameter
+\var{_maintype} is the \mailheader{Content-Type} major type
+(e.g. \mimetype{text} or \mimetype{image}), and \var{_subtype} is the
+\mailheader{Content-Type} minor type 
+(e.g. \mimetype{plain} or \mimetype{gif}).  \var{_params} is a parameter
 key/value dictionary and is passed directly to
 \method{Message.add_header()}.
 
@@ -195,10 +134,11 @@
 
 \begin{classdesc}{MIMEText}{_text\optional{, _subtype\optional{,
     _charset\optional{, _encoder}}}}
+
 A subclass of \class{MIMEBase}, the \class{MIMEText} class is used to
-create MIME objects of major type \mimetype{text}.  \var{_text} is the string
-for the payload.  \var{_subtype} is the minor type and defaults to
-\mimetype{plain}.  \var{_charset} is the character set of the text and is
+create MIME objects of major type \mimetype{text}.  \var{_text} is the
+string for the payload.  \var{_subtype} is the minor type and defaults
+to \mimetype{plain}.  \var{_charset} is the character set of the text and is
 passed as a parameter to the \class{MIMEBase} constructor; it defaults
 to \code{us-ascii}.  No guessing or encoding is performed on the text
 data, but a newline is appended to \var{_text} if it doesn't already
@@ -221,27 +161,24 @@
 to \mimetype{rfc822}.
 \end{classdesc}
 
-\subsection{Encoders, Exceptions, Utilities, and Iterators}
+\subsection{Encoders}
+\input{emailencoders}
 
-The \module{email} package provides various encoders for safe
-transport of binary payloads in \class{MIMEImage} and \class{MIMEText}
-instances.  See the \refmodule{email.Encoders} module for more
-details.
+\subsection{Exception classes}
+\input{emailexc}
 
-All of the class exceptions that the \module{email} package can raise
-are available in the \refmodule{email.Errors} module.
+\subsection{Miscellaneous utilities}
+\input{emailutil}
 
-Some miscellaneous utility functions are available in the
-\refmodule{email.Utils} module.
-
-Iterating over a message object tree is easy with the
-\method{Message.walk()} method; some additional helper iterators are
-available in the \refmodule{email.Iterators} module.
+\subsection{Iterators}
+\input{emailiter}
 
 \subsection{Differences from \module{mimelib}}
 
 The \module{email} package was originally prototyped as a separate
-library called \module{mimelib}.  Changes have been made so that
+library called
+\ulink{\module{mimelib}}{http://mimelib.sf.net/}.
+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
@@ -282,7 +219,7 @@
       \method{get_params()}.
       Also, whereas \method{getparams()} returned a list of strings,
       \method{get_params()} returns a list of 2-tuples, effectively
-      the key/value pairs of the parameters, split on the \samp{=}
+      the key/value pairs of the parameters, split on the \character{=}
       sign.
 \item The method \method{getparam()} was renamed to \method{get_param()}.
 \item The method \method{getcharsets()} was renamed to
@@ -355,4 +292,3 @@
 \subsection{Examples}
 
 Coming soon...
-