Provided by: libmime-tools-perl_5.509-1_all bug

NAME

       MIME::Entity - class for parsed-and-decoded MIME message

SYNOPSIS

       Before reading further, you should see MIME::Tools to make sure that you understand where
       this module fits into the grand scheme of things.  Go on, do it now.  I'll wait.

       Ready?  Ok...

           ### Create an entity:
           $top = MIME::Entity->build(From    => 'me@myhost.com',
                                      To      => 'you@yourhost.com',
                                      Subject => "Hello, nurse!",
                                      Data    => \@my_message);

           ### Attach stuff to it:
           $top->attach(Path     => $gif_path,
                        Type     => "image/gif",
                        Encoding => "base64");

           ### Sign it:
           $top->sign;

           ### Output it:
           $top->print(\*STDOUT);

DESCRIPTION

       A subclass of Mail::Internet.

       This package provides a class for representing MIME message entities, as specified in RFCs
       2045, 2046, 2047, 2048 and 2049.

EXAMPLES

   Construction examples
       Create a document for an ordinary 7-bit ASCII text file (lots of stuff is defaulted for
       us):

           $ent = MIME::Entity->build(Path=>"english-msg.txt");

       Create a document for a text file with 8-bit (Latin-1) characters:

           $ent = MIME::Entity->build(Path     =>"french-msg.txt",
                                      Encoding =>"quoted-printable",
                                      From     =>'jean.luc@inria.fr',
                                      Subject  =>"C'est bon!");

       Create a document for a GIF file (the description is completely optional; note that we
       have to specify content-type and encoding since they're not the default values):

           $ent = MIME::Entity->build(Description => "A pretty picture",
                                      Path        => "./docs/mime-sm.gif",
                                      Type        => "image/gif",
                                      Encoding    => "base64");

       Create a document that you already have the text for, using "Data":

           $ent = MIME::Entity->build(Type        => "text/plain",
                                      Encoding    => "quoted-printable",
                                      Data        => ["First line.\n",
                                                     "Second line.\n",
                                                     "Last line.\n"]);

       Create a multipart message, with the entire structure given explicitly:

           ### Create the top-level, and set up the mail headers:
           $top = MIME::Entity->build(Type     => "multipart/mixed",
                                      From     => 'me@myhost.com',
                                      To       => 'you@yourhost.com',
                                      Subject  => "Hello, nurse!");

           ### Attachment #1: a simple text document:
           $top->attach(Path=>"./testin/short.txt");

           ### Attachment #2: a GIF file:
           $top->attach(Path        => "./docs/mime-sm.gif",
                        Type        => "image/gif",
                        Encoding    => "base64");

           ### Attachment #3: text we'll create with text we have on-hand:
           $top->attach(Data => $contents);

       Suppose you don't know ahead of time that you'll have attachments?  No problem: you can
       "attach" to singleparts as well:

           $top = MIME::Entity->build(From    => 'me@myhost.com',
                                      To      => 'you@yourhost.com',
                                      Subject => "Hello, nurse!",
                                      Data    => \@my_message);
           if ($GIF_path) {
               $top->attach(Path     => $GIF_path,
                            Type     => 'image/gif');
           }

       Copy an entity (headers, parts... everything but external body data):

           my $deepcopy = $top->dup;

   Access examples
           ### Get the head, a MIME::Head:
           $head = $ent->head;

           ### Get the body, as a MIME::Body;
           $bodyh = $ent->bodyhandle;

           ### Get the intended MIME type (as declared in the header):
           $type = $ent->mime_type;

           ### Get the effective MIME type (in case decoding failed):
           $eff_type = $ent->effective_type;

           ### Get preamble, parts, and epilogue:
           $preamble   = $ent->preamble;          ### ref to array of lines
           $num_parts  = $ent->parts;
           $first_part = $ent->parts(0);          ### an entity
           $epilogue   = $ent->epilogue;          ### ref to array of lines

   Manipulation examples
       Muck about with the body data:

           ### Read the (unencoded) body data:
           if ($io = $ent->open("r")) {
               while (defined($_ = $io->getline)) { print $_ }
               $io->close;
           }

           ### Write the (unencoded) body data:
           if ($io = $ent->open("w")) {
               foreach (@lines) { $io->print($_) }
               $io->close;
           }

           ### Delete the files for any external (on-disk) data:
           $ent->purge;

       Muck about with the signature:

           ### Sign it (automatically removes any existing signature):
           $top->sign(File=>"$ENV{HOME}/.signature");

           ### Remove any signature within 15 lines of the end:
           $top->remove_sig(15);

       Muck about with the headers:

           ### Compute content-lengths for singleparts based on bodies:
           ###   (Do this right before you print!)
           $entity->sync_headers(Length=>'COMPUTE');

       Muck about with the structure:

           ### If a 0- or 1-part multipart, collapse to a singlepart:
           $top->make_singlepart;

           ### If a singlepart, inflate to a multipart with 1 part:
           $top->make_multipart;

       Delete parts:

           ### Delete some parts of a multipart message:
           my @keep = grep { keep_part($_) } $msg->parts;
           $msg->parts(\@keep);

   Output examples
       Print to filehandles:

           ### Print the entire message:
           $top->print(\*STDOUT);

           ### Print just the header:
           $top->print_header(\*STDOUT);

           ### Print just the (encoded) body... includes parts as well!
           $top->print_body(\*STDOUT);

       Stringify... note that "stringify_xx" can also be written "xx_as_string"; the methods are
       synonymous, and neither form will be deprecated.

       If you set the variable $MIME::Entity::BOUNDARY_DELIMITER to a string, that string will be
       used as the line-end delimiter on output.  If it is not set, the line ending will be a
       newline character (\n)

       NOTE that $MIME::Entity::BOUNDARY_DELIMITER only applies to structural parts of the MIME
       data generated by this package and to the Base64 encoded output; if a part internally uses
       a different line-end delimiter and is output as-is, the line-ending is not changed to
       match $MIME::Entity::BOUNDARY_DELIMITER.

           ### Stringify the entire message:
           print $top->stringify;              ### or $top->as_string

           ### Stringify just the header:
           print $top->stringify_header;       ### or $top->header_as_string

           ### Stringify just the (encoded) body... includes parts as well!
           print $top->stringify_body;         ### or $top->body_as_string

       Debug:

           ### Output debugging info:
           $entity->dump_skeleton(\*STDERR);

PUBLIC INTERFACE

   Construction
       new [SOURCE]
           Class method.  Create a new, empty MIME entity.  Basically, this uses the
           Mail::Internet constructor...

           If SOURCE is an ARRAYREF, it is assumed to be an array of lines that will be used to
           create both the header and an in-core body.

           Else, if SOURCE is defined, it is assumed to be a filehandle from which the header and
           in-core body is to be read.

           Note: in either case, the body will not be parsed: merely read!

       add_part ENTITY, [OFFSET]
           Instance method.  Assuming we are a multipart message, add a body part (a
           MIME::Entity) to the array of body parts.  Returns the part that was just added.

           If OFFSET is positive, the new part is added at that offset from the beginning of the
           array of parts.  If it is negative, it counts from the end of the array.  (An INDEX of
           -1 will place the new part at the very end of the array, -2 will place it as the
           penultimate item in the array, etc.)  If OFFSET is not given, the new part is added to
           the end of the array.  Thanks to Jason L Tibbitts III for providing support for
           OFFSET.

           Warning: in general, you only want to attach parts to entities with a content-type of
           "multipart/*").

       attach PARAMHASH
           Instance method.  The real quick-and-easy way to create multipart messages.  The
           PARAMHASH is used to "build" a new entity; this method is basically equivalent to:

               $entity->add_part(ref($entity)->build(PARAMHASH, Top=>0));

           Note: normally, you attach to multipart entities; however, if you attach something to
           a singlepart (like attaching a GIF to a text message), the singlepart will be coerced
           into a multipart automatically.

       build PARAMHASH
           Class/instance method.  A quick-and-easy catch-all way to create an entity.  Use it
           like this to build a "normal" single-part entity:

              $ent = MIME::Entity->build(Type     => "image/gif",
                                         Encoding => "base64",
                                         Path     => "/path/to/xyz12345.gif",
                                         Filename => "saveme.gif",
                                         Disposition => "attachment");

           And like this to build a "multipart" entity:

              $ent = MIME::Entity->build(Type     => "multipart/mixed",
                                         Boundary => "---1234567");

           A minimal MIME header will be created.  If you want to add or modify any header fields
           afterwards, you can of course do so via the underlying head object... but hey, there's
           now a prettier syntax!

              $ent = MIME::Entity->build(Type          =>"multipart/mixed",
                                         From          => $myaddr,
                                         Subject       => "Hi!",
                                         'X-Certified' => ['SINED',
                                                           'SEELED',
                                                           'DELIVERED']);

           Normally, an "X-Mailer" header field is output which contains this toolkit's name and
           version (plus this module's RCS version).  This will allow any bad MIME we generate to
           be traced back to us.  You can of course overwrite that header with your own:

              $ent = MIME::Entity->build(Type        => "multipart/mixed",
                                         'X-Mailer'  => "myprog 1.1");

           Or remove it entirely:

              $ent = MIME::Entity->build(Type       => "multipart/mixed",
                                         'X-Mailer' => undef);

           OK, enough hype.  The parameters are:

           (FIELDNAME)
               Any field you want placed in the message header, taken from the standard list of
               header fields (you don't need to worry about case):

                   Bcc           Encrypted     Received      Sender
                   Cc            From          References    Subject
                   Comments      Keywords      Reply-To      To
                   Content-*     Message-ID    Resent-*      X-*
                   Date          MIME-Version  Return-Path
                                 Organization

               To give experienced users some veto power, these fields will be set after the ones
               I set... so be careful: don't set any MIME fields (like "Content-type") unless you
               know what you're doing!

               To specify a fieldname that's not in the above list, even one that's identical to
               an option below, just give it with a trailing ":", like "My-field:".  When in
               doubt, that always signals a mail field (and it sort of looks like one too).

           Boundary
               Multipart entities only. Optional.  The boundary string.  As per RFC-2046, it must
               consist only of the characters "[0-9a-zA-Z'()+_,-./:=?]" and space (you'll be
               warned, and your boundary will be ignored, if this is not the case).  If you omit
               this, a random string will be chosen... which is probably safer.

           Charset
               Optional.  The character set.

           Data
               Single-part entities only. Optional.  An alternative to Path (q.v.): the actual
               data, either as a scalar or an array reference (whose elements are joined together
               to make the actual scalar).  The body is opened on the data using
               MIME::Body::InCore.

           Description
               Optional.  The text of the content-description.  If you don't specify it, the
               field is not put in the header.

           Disposition
               Optional.  The basic content-disposition ("attachment" or "inline").  If you don't
               specify it, it defaults to "inline" for backwards compatibility.  Thanks to Kurt
               Freytag for suggesting this feature.

           Encoding
               Optional.  The content-transfer-encoding.  If you don't specify it, a reasonable
               default is put in.  You can also give the special value '-SUGGEST', to have it
               chosen for you in a heavy-duty fashion which scans the data itself.

           Filename
               Single-part entities only. Optional.  The recommended filename.  Overrides any
               name extracted from "Path".  The information is stored both the deprecated
               (content-type) and preferred (content-disposition) locations.  If you explicitly
               want to avoid a recommended filename (even when Path is used), supply this as
               empty or undef.

           Id  Optional.  Set the content-id.

           Path
               Single-part entities only. Optional.  The path to the file to attach.  The body is
               opened on that file using MIME::Body::File.

           Top Optional.  Is this a top-level entity?  If so, it must sport a MIME-Version.  The
               default is true.  (NB: look at how "attach()" uses it.)

           Type
               Optional.  The basic content-type ("text/plain", etc.).  If you don't specify it,
               it defaults to "text/plain" as per RFC 2045.  Do yourself a favor: put it in.

       dup Instance method.  Duplicate the entity.  Does a deep, recursive copy, but beware:
           external data in bodyhandles is not copied to new files!  Changing the data in one
           entity's data file, or purging that entity, will affect its duplicate.  Entities with
           in-core data probably need not worry.

   Access
       body [VALUE]
           Instance method.  Get the encoded (transport-ready) body, as an array of lines.
           Returns an array reference.  Each array entry is a newline-terminated line.

           This is a read-only data structure: changing its contents will have no effect.  Its
           contents are identical to what is printed by print_body().

           Provided for compatibility with Mail::Internet, so that methods like "smtpsend()" will
           work.  Note however that if VALUE is given, a fatal exception is thrown, since you
           cannot use this method to set the lines of the encoded message.

           If you want the raw (unencoded) body data, use the bodyhandle() method to get and use
           a MIME::Body.  The content-type of the entity will tell you whether that body is best
           read as text (via getline()) or raw data (via read()).

       bodyhandle [VALUE]
           Instance method.  Get or set an abstract object representing the body of the message.
           The body holds the decoded message data.

           Note that not all entities have bodies!  An entity will have either a body or parts:
           not both.  This method will only return an object if this entity can have a body;
           otherwise, it will return undefined.  Whether-or-not a given entity can have a body is
           determined by (1) its content type, and (2) whether-or-not the parser was told to
           extract nested messages:

               Type:        | Extract nested? | bodyhandle() | parts()
               -----------------------------------------------------------------------
               multipart/*  | -               | undef        | 0 or more MIME::Entity
               message/*    | true            | undef        | 0 or 1 MIME::Entity
               message/*    | false           | MIME::Body   | empty list
               (other)      | -               | MIME::Body   | empty list

           If "VALUE" is not given, the current bodyhandle is returned, or undef if the entity
           cannot have a body.

           If "VALUE" is given, the bodyhandle is set to the new value, and the previous value is
           returned.

           See "parts" for more info.

       effective_type [MIMETYPE]
           Instance method.  Set/get the effective MIME type of this entity.  This is usually
           identical to the actual (or defaulted) MIME type, but in some cases it differs.  For
           example, from RFC-2045:

              Any entity with an unrecognized Content-Transfer-Encoding must be
              treated as if it has a Content-Type of "application/octet-stream",
              regardless of what the Content-Type header field actually says.

           Why? because if we can't decode the message, then we have to take the bytes as-is, in
           their (unrecognized) encoded form.  So the message ceases to be a "text/foobar" and
           becomes a bunch of undecipherable bytes -- in other words, an
           "application/octet-stream".

           Such an entity, if parsed, would have its effective_type() set to
           "application/octet_stream", although the mime_type() and the contents of the header
           would remain the same.

           If there is no effective type, the method just returns what mime_type() would.

           Warning: the effective type is "sticky"; once set, that effective_type() will always
           be returned even if the conditions that necessitated setting the effective type become
           no longer true.

       epilogue [LINES]
           Instance method.  Get/set the text of the epilogue, as an array of newline-terminated
           LINES.  Returns a reference to the array of lines, or undef if no epilogue exists.

           If there is a epilogue, it is output when printing this entity; otherwise, a default
           epilogue is used.  Setting the epilogue to undef (not []!) causes it to fallback to
           the default.

       head [VALUE]
           Instance method.  Get/set the head.

           If there is no VALUE given, returns the current head.  If none exists, an empty
           instance of MIME::Head is created, set, and returned.

           Note: This is a patch over a problem in Mail::Internet, which doesn't provide a method
           for setting the head to some given object.

       is_multipart
           Instance method.  Does this entity's effective MIME type indicate that it's a
           multipart entity?  Returns undef (false) if the answer couldn't be determined, 0
           (false) if it was determined to be false, and true otherwise.  Note that this says
           nothing about whether or not parts were extracted.

           NOTE: we switched to effective_type so that multiparts with bad or missing boundaries
           could be coerced to an effective type of "application/x-unparseable-multipart".

       mime_type
           Instance method.  A purely-for-convenience method.  This simply relays the request to
           the associated MIME::Head object.  If there is no head, returns undef in a scalar
           context and the empty array in a list context.

           Before you use this, consider using effective_type() instead, especially if you
           obtained the entity from a MIME::Parser.

       open READWRITE
           Instance method.  A purely-for-convenience method.  This simply relays the request to
           the associated MIME::Body object (see MIME::Body::open()).  READWRITE is either 'r'
           (open for read) or 'w' (open for write).

           If there is no body, returns false.

       parts
       parts INDEX
       parts ARRAYREF
           Instance method.  Return the MIME::Entity objects which are the sub parts of this
           entity (if any).

           If no argument is given, returns the array of all sub parts, returning the empty array
           if there are none (e.g., if this is a single part message, or a degenerate multipart).
           In a scalar context, this returns you the number of parts.

           If an integer INDEX is given, return the INDEXed part, or undef if it doesn't exist.

           If an ARRAYREF to an array of parts is given, then this method sets the parts to a
           copy of that array, and returns the parts.  This can be used to delete parts, as
           follows:

               ### Delete some parts of a multipart message:
               $msg->parts([ grep { keep_part($_) } $msg->parts ]);

           Note: for multipart messages, the preamble and epilogue are not considered parts.  If
           you need them, use the "preamble()" and "epilogue()" methods.

           Note: there are ways of parsing with a MIME::Parser which cause certain message parts
           (such as those of type "message/rfc822") to be "reparsed" into pseudo-multipart
           entities.  You should read the documentation for those options carefully: it is
           possible for a diddled entity to not be multipart, but still have parts attached to
           it!

           See "bodyhandle" for a discussion of parts vs. bodies.

       parts_DFS
           Instance method.  Return the list of all MIME::Entity objects included in the entity,
           starting with the entity itself, in depth-first-search order.  If the entity has no
           parts, it alone will be returned.

           Thanks to Xavier Armengou for suggesting this method.

       preamble [LINES]
           Instance method.  Get/set the text of the preamble, as an array of newline-terminated
           LINES.  Returns a reference to the array of lines, or undef if no preamble exists
           (e.g., if this is a single-part entity).

           If there is a preamble, it is output when printing this entity; otherwise, a default
           preamble is used.  Setting the preamble to undef (not []!) causes it to fallback to
           the default.

   Manipulation
       make_multipart [SUBTYPE], OPTSHASH...
           Instance method.  Force the entity to be a multipart, if it isn't already.  We do this
           by replacing the original [singlepart] entity with a new multipart that has the same
           non-MIME headers ("From", "Subject", etc.), but all-new MIME headers ("Content-type",
           etc.).  We then create a copy of the original singlepart, strip out the non-MIME
           headers from that, and make it a part of the new multipart.  So this:

               From: me
               To: you
               Content-type: text/plain
               Content-length: 12

               Hello there!

           Becomes something like this:

               From: me
               To: you
               Content-type: multipart/mixed; boundary="----abc----"

               ------abc----
               Content-type: text/plain
               Content-length: 12

               Hello there!

               ------abc------
           The actual type of the new top-level multipart will be "multipart/SUBTYPE" (default
           SUBTYPE is "mixed").

           Returns 'DONE'    if we really did inflate a singlepart to a multipart.  Returns
           'ALREADY' (and does nothing) if entity is already multipart and Force was not chosen.

           If OPTSHASH contains Force=>1, then we always bump the top-level's content and
           content-headers down to a subpart of this entity, even if this entity is already a
           multipart.  This is apparently of use to people who are tweaking messages after
           parsing them.

       make_singlepart
           Instance method.  If the entity is a multipart message with one part, this tries hard
           to rewrite it as a singlepart, by replacing the content (and content headers) of the
           top level with those of the part.  Also crunches 0-part multiparts into singleparts.

           Returns 'DONE'    if we really did collapse a multipart to a singlepart.  Returns
           'ALREADY' (and does nothing) if entity is already a singlepart.  Returns '0'
           (and does nothing) if it can't be made into a singlepart.

       purge
           Instance method.  Recursively purge (e.g., unlink) all external (e.g., on-disk) body
           parts in this message.  See MIME::Body::purge() for details.

           Note: this does not delete the directories that those body parts are contained in;
           only the actual message data files are deleted.  This is because some parsers may be
           customized to create intermediate directories while others are not, and it's
           impossible for this class to know what directories are safe to remove.  Only your
           application program truly knows that.

           If you really want to "clean everything up", one good way is to use
           "MIME::Parser::file_under()", and then do this before parsing your next message:

               $parser->filer->purge();

           I wouldn't attempt to read those body files after you do this, for obvious reasons.
           As of MIME-tools 4.x, each body's path is undefined after this operation.  I warned
           you I might do this; truly I did.

           Thanks to Jason L. Tibbitts III for suggesting this method.

       remove_sig [NLINES]
           Instance method, override.  Attempts to remove a user's signature from the body of a
           message.

           It does this by looking for a line matching "/^-- $/" within the last "NLINES" of the
           message.  If found then that line and all lines after it will be removed. If "NLINES"
           is not given, a default value of 10 will be used.  This would be of most use in auto-
           reply scripts.

           For MIME entity, this method is reasonably cautious: it will only attempt to un-sign a
           message with a content-type of "text/*".

           If you send remove_sig() to a multipart entity, it will relay it to the first part
           (the others usually being the "attachments").

           Warning: currently slurps the whole message-part into core as an array of lines, so
           you probably don't want to use this on extremely long messages.

           Returns truth on success, false on error.

       sign PARAMHASH
           Instance method, override.  Append a signature to the message.  The params are:

           Attach
               Instead of appending the text, add it to the message as an attachment.  The
               disposition will be "inline", and the description will indicate that it is a
               signature.  The default behavior is to append the signature to the text of the
               message (or the text of its first part if multipart).  MIME-specific; new in this
               subclass.

           File
               Use the contents of this file as the signature.  Fatal error if it can't be read.
               As per superclass method.

           Force
               Sign it even if the content-type isn't "text/*".  Useful for non-standard types
               like "x-foobar", but be careful!  MIME-specific; new in this subclass.

           Remove
               Normally, we attempt to strip out any existing signature.  If true, this gives us
               the NLINES parameter of the remove_sig call.  If zero but defined, tells us not to
               remove any existing signature.  If undefined, removal is done with the default of
               10 lines.  New in this subclass.

           Signature
               Use this text as the signature.  You can supply it as either a scalar, or as a ref
               to an array of newline-terminated scalars.  As per superclass method.

           For MIME messages, this method is reasonably cautious: it will only attempt to sign a
           message with a content-type of "text/*", unless "Force" is specified.

           If you send this message to a multipart entity, it will relay it to the first part
           (the others usually being the "attachments").

           Warning: currently slurps the whole message-part into core as an array of lines, so
           you probably don't want to use this on extremely long messages.

           Returns true on success, false otherwise.

       suggest_encoding
           Instance method.  Based on the effective content type, return a good suggested
           encoding.

           "text" and "message" types have their bodies scanned line-by-line for 8-bit characters
           and long lines; lack of either means that the message is 7bit-ok.  Other types are
           chosen independent of their body:

               Major type:      7bit ok?    Suggested encoding:
               -----------------------------------------------------------
               text             yes         7bit
               text             no          quoted-printable
               message          yes         7bit
               message          no          binary
               multipart        *           binary (in case some parts are bad)
               image, etc...    *           base64

       sync_headers OPTIONS
           Instance method.  This method does a variety of activities which ensure that the MIME
           headers of an entity "tree" are in-synch with the body parts they describe.  It can be
           as expensive an operation as printing if it involves pre-encoding the body parts;
           however, the aim is to produce fairly clean MIME.  You will usually only need to
           invoke this if processing and re-sending MIME from an outside source.

           The OPTIONS is a hash, which describes what is to be done.

           Length
               One of the "official unofficial" MIME fields is "Content-Length".  Normally, one
               doesn't care a whit about this field; however, if you are preparing output
               destined for HTTP, you may.  The value of this option dictates what will be done:

               COMPUTE means to set a "Content-Length" field for every non-multipart part in the
               entity, and to blank that field out for every multipart part in the entity.

               ERASE means that "Content-Length" fields will all be blanked out.  This is fast,
               painless, and safe.

               Any false value (the default) means to take no action.

           Nonstandard
               Any header field beginning with "Content-" is, according to the RFC, a MIME field.
               However, some are non-standard, and may cause problems with certain MIME readers
               which interpret them in different ways.

               ERASE means that all such fields will be blanked out.  This is done before the
               Length option (q.v.) is examined and acted upon.

               Any false value (the default) means to take no action.

           Returns a true value if everything went okay, a false value otherwise.

       tidy_body
           Instance method, override.  Currently unimplemented for MIME messages.  Does nothing,
           returns false.

   Output
       dump_skeleton [FILEHANDLE]
           Instance method.  Dump the skeleton of the entity to the given FILEHANDLE, or to the
           currently-selected one if none given.

           Each entity is output with an appropriate indentation level, the following selection
           of attributes:

               Content-type: multipart/mixed
               Effective-type: multipart/mixed
               Body-file: NONE
               Subject: Hey there!
               Num-parts: 2

           This is really just useful for debugging purposes; I make no guarantees about the
           consistency of the output format over time.

       print [OUTSTREAM]
           Instance method, override.  Print the entity to the given OUTSTREAM, or to the
           currently-selected filehandle if none given.  OUTSTREAM can be a filehandle, or any
           object that responds to a print() message.

           The entity is output as a valid MIME stream!  This means that the header is always
           output first, and the body data (if any) will be encoded if the header says that it
           should be.  For example, your output may look like this:

               Subject: Greetings
               Content-transfer-encoding: base64

               SGkgdGhlcmUhCkJ5ZSB0aGVyZSEK

           If this entity has MIME type "multipart/*", the preamble, parts, and epilogue are all
           output with appropriate boundaries separating each.  Any bodyhandle is ignored:

               Content-type: multipart/mixed; boundary="*----*"
               Content-transfer-encoding: 7bit

               [Preamble]
               --*----*
               [Entity: Part 0]
               --*----*
               [Entity: Part 1]
               --*----*--
               [Epilogue]

           If this entity has a single-part MIME type with no attached parts, then we're looking
           at a normal singlepart entity: the body is output according to the encoding specified
           by the header.  If no body exists, a warning is output and the body is treated as
           empty:

               Content-type: image/gif
               Content-transfer-encoding: base64

               [Encoded body]

           If this entity has a single-part MIME type but it also has parts, then we're probably
           looking at a "re-parsed" singlepart, usually one of type "message/*" (you can get
           entities like this if you set the "parse_nested_messages(NEST)" option on the parser
           to true).  In this case, the parts are output with single blank lines separating each,
           and any bodyhandle is ignored:

               Content-type: message/rfc822
               Content-transfer-encoding: 7bit

               [Entity: Part 0]

               [Entity: Part 1]

           In all cases, when outputting a "part" of the entity, this method is invoked
           recursively.

           Note: the output is very likely not going to be identical to any input you parsed to
           get this entity.  If you're building some sort of email handler, it's up to you to
           save this information.

       print_body [OUTSTREAM]
           Instance method, override.  Print the body of the entity to the given OUTSTREAM, or to
           the currently-selected filehandle if none given.  OUTSTREAM can be a filehandle, or
           any object that responds to a print() message.

           The body is output for inclusion in a valid MIME stream; this means that the body data
           will be encoded if the header says that it should be.

           Note: by "body", we mean "the stuff following the header".  A printed multipart body
           includes the printed representations of its subparts.

           Note: The body is stored in an un-encoded form; however, the idea is that the transfer
           encoding is used to determine how it should be output.  This means that the "print()"
           method is always guaranteed to get you a sendmail-ready stream whose body is
           consistent with its head.  If you want the raw body data to be output, you can either
           read it from the bodyhandle yourself, or use:

               $ent->bodyhandle->print($outstream);

           which uses read() calls to extract the information, and thus will work with both text
           and binary bodies.

           Warning: Please supply an OUTSTREAM.  This override method differs from
           Mail::Internet's behavior, which outputs to the STDOUT if no filehandle is given: this
           may lead to confusion.

       print_header [OUTSTREAM]
           Instance method, inherited.  Output the header to the given OUTSTREAM.  You really
           should supply the OUTSTREAM.

       stringify
           Instance method.  Return the entity as a string, exactly as "print" would print it.
           The body will be encoded as necessary, and will contain any subparts.  You can also
           use "as_string()".

       stringify_body
           Instance method.  Return the encoded message body as a string, exactly as "print_body"
           would print it.  You can also use "body_as_string()".

           If you want the unencoded body, and you are dealing with a singlepart message (like a
           "text/plain"), use "bodyhandle()" instead:

               if ($ent->bodyhandle) {
                   $unencoded_data = $ent->bodyhandle->as_string;
               }
               else {
                   ### this message has no body data (but it might have parts!)
               }

       stringify_header
           Instance method.  Return the header as a string, exactly as "print_header" would print
           it.  You can also use "header_as_string()".

NOTES

   Under the hood
       A MIME::Entity is composed of the following elements:

       •   A head, which is a reference to a MIME::Head object containing the header information.

       •   A bodyhandle, which is a reference to a MIME::Body object containing the decoded body
           data.  This is only defined if the message is a "singlepart" type:

               application/*
               audio/*
               image/*
               text/*
               video/*

       •   An array of parts, where each part is a MIME::Entity object.  The number of parts will
           only be nonzero if the content-type is not one of the "singlepart" types:

               message/*        (should have exactly one part)
               multipart/*      (should have one or more parts)

   The "two-body problem"
       MIME::Entity and Mail::Internet see message bodies differently, and this can cause
       confusion and some inconvenience.  Sadly, I can't change the behavior of MIME::Entity
       without breaking lots of code already out there.  But let's open up the floor for a few
       questions...

       What is the difference between a "message" and an "entity"?
           A message is the actual data being sent or received; usually this means a stream of
           newline-terminated lines.  An entity is the representation of a message as an object.

           This means that you get a "message" when you print an "entity" to a filehandle, and
           you get an "entity" when you parse a message from a filehandle.

       What is a message body?
           Mail::Internet: The portion of the printed message after the header.

           MIME::Entity: The portion of the printed message after the header.

       How is a message body stored in an entity?
           Mail::Internet: As an array of lines.

           MIME::Entity: It depends on the content-type of the message.  For "container" types
           ("multipart/*", "message/*"), we store the contained entities as an array of "parts",
           accessed via the "parts()" method, where each part is a complete MIME::Entity.  For
           "singlepart" types ("text/*", "image/*", etc.), the unencoded body data is referenced
           via a MIME::Body object, accessed via the "bodyhandle()" method:

                                 bodyhandle()   parts()
               Content-type:     returns:       returns:
               ------------------------------------------------------------
               application/*     MIME::Body     empty
               audio/*           MIME::Body     empty
               image/*           MIME::Body     empty
               message/*         undef          MIME::Entity list (usually 1)
               multipart/*       undef          MIME::Entity list (usually >0)
               text/*            MIME::Body     empty
               video/*           MIME::Body     empty
               x-*/*             MIME::Body     empty

           As a special case, "message/*" is currently ambiguous: depending on the parser, a
           "message/*" might be treated as a singlepart, with a MIME::Body and no parts.  Use
           bodyhandle() as the final arbiter.

       What does the body() method return?
           Mail::Internet: As an array of lines, ready for sending.

           MIME::Entity: As an array of lines, ready for sending.

       What's the best way to get at the body data?
           Mail::Internet: Use the body() method.

           MIME::Entity: Depends on what you want... the encoded data (as it is transported), or
           the unencoded data?  Keep reading...

       How do I get the "encoded" body data?
           Mail::Internet: Use the body() method.

           MIME::Entity: Use the body() method.  You can also use:

               $entity->print_body()
               $entity->stringify_body()   ### a.k.a. $entity->body_as_string()

       How do I get the "unencoded" body data?
           Mail::Internet: Use the body() method.

           MIME::Entity: Use the bodyhandle() method!  If bodyhandle() method returns true, then
           that value is a MIME::Body which can be used to access the data via its open() method.
           If bodyhandle() method returns an undefined value, then the entity is probably a
           "container" that has no real body data of its own (e.g., a "multipart" message): in
           this case, you should access the components via the parts() method.  Like this:

               if ($bh = $entity->bodyhandle) {
                   $io = $bh->open;
                   ...access unencoded data via $io->getline or $io->read...
                   $io->close;
               }
               else {
                   foreach my $part (@parts) {
                       ...do something with the part...
                   }
               }

           You can also use:

               if ($bh = $entity->bodyhandle) {
                   $unencoded_data = $bh->as_string;
               }
               else {
                   ...do stuff with the parts...
               }

       What does the body() method return?
           Mail::Internet: The transport-encoded message body, as an array of lines.

           MIME::Entity: The transport-encoded message body, as an array of lines.

       What does print_body() print?
           Mail::Internet: Exactly what body() would return to you.

           MIME::Entity: Exactly what body() would return to you.

       Say I have an entity which might be either singlepart or multipart. How do I print out
       just "the stuff after the header"?
           Mail::Internet: Use print_body().

           MIME::Entity: Use print_body().

       Why is MIME::Entity so different from Mail::Internet?
           Because MIME streams are expected to have non-textual data...  possibly, quite a lot
           of it, such as a tar file.

           Because MIME messages can consist of multiple parts, which are most-easily manipulated
           as MIME::Entity objects themselves.

           Because in the simpler world of Mail::Internet, the data of a message and its printed
           representation are identical... and in the MIME world, they're not.

           Because parsing multipart bodies on-the-fly, or formatting multipart bodies for
           output, is a non-trivial task.

       This is confusing.  Can the two classes be made more compatible?
           Not easily; their implementations are necessarily quite different.  Mail::Internet is
           a simple, efficient way of dealing with a "black box" mail message... one whose
           internal data you don't care much about.  MIME::Entity, in contrast, cares very much
           about the message contents: that's its job!

   Design issues
       Some things just can't be ignored
           In multipart messages, the "preamble" is the portion that precedes the first
           encapsulation boundary, and the "epilogue" is the portion that follows the last
           encapsulation boundary.

           According to RFC 2046:

               There appears to be room for additional information prior
               to the first encapsulation boundary and following the final
               boundary.  These areas should generally be left blank, and
               implementations must ignore anything that appears before the
               first boundary or after the last one.

               NOTE: These "preamble" and "epilogue" areas are generally
               not used because of the lack of proper typing of these parts
               and the lack of clear semantics for handling these areas at
               gateways, particularly X.400 gateways.  However, rather than
               leaving the preamble area blank, many MIME implementations
               have found this to be a convenient place to insert an
               explanatory note for recipients who read the message with
               pre-MIME software, since such notes will be ignored by
               MIME-compliant software.

           In the world of standards-and-practices, that's the standard.  Now for the practice:

           Some "MIME" mailers may incorrectly put a "part" in the preamble.  Since we have to
           parse over the stuff anyway, in the future I may allow the parser option of creating
           special MIME::Entity objects for the preamble and epilogue, with bogus MIME::Head
           objects.

           For now, though, we're MIME-compliant, so I probably won't change how we work.

SEE ALSO

       MIME::Tools, MIME::Head, MIME::Body, MIME::Decoder, Mail::Internet

AUTHOR

       Eryq (eryq@zeegee.com), ZeeGee Software Inc (http://www.zeegee.com).  Dianne Skoll
       (dfs@roaringpenguin.com) http://www.roaringpenguin.com

       All rights reserved.  This program is free software; you can redistribute it and/or modify
       it under the same terms as Perl itself.