NAME
MIME::Parser - experimental class for parsing MIME streams
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... BBaassiicc uussaaggee eexxaammpplleess### Create a new parser object:
my $parser = new MIME::Parser;
### Tell it where to put things:
$parser->outputunder("/tmp");
### Parse an input filehandle:
$entity = $parser->parse(\*STDIN);
### Congratulations: you now have a (possibly multipart) MIME entity!
$entity->dumpskeleton; # for debugging
EExxaammpplleess ooff iinnppuutt### Parse from filehandles:
$entity = $parser->parse(\*STDIN);
$entity = $parser->parse(IO::File->new("some command|");
### Parse from any object that supports getline() and read():
$entity = $parser->parse($myHandle);
### Parse an in-core MIME message:
$entity = $parser->parsedata($message);
### Parse an MIME message in a file:
$entity = $parser->parseopen("/some/file.msg");
### Parse an MIME message out of a pipeline:
$entity = $parser->parseopen("gunzip - < file.msg.gz |");
### Parse already-split input (as "deliver" would give it to you):
$entity = $parser->parsetwo("msg.head", "msg.body");
EExxaammpplleess ooff oouuttppuutt ccoonnttrrooll### Keep parsed message bodies in core (default outputs to disk):
$parser->outputtocore(1);
### Output each message body to a one-per-message directory:
$parser->outputunder("/tmp");
### Output each message body to the same directory:
$parser->outputdir("/tmp");
### Change how nameless message-component files are named:
$parser->outputprefix("msg");
EExxaammpplleess ooff eerrrroorr rreeccoovveerryy### Normal mechanism:
eval { $entity = $parser->parse(\*STDIN) };
if ($@) {
$results = $parser->results;
$decapitated = $parser->lasthead; ### get last top-level head
}### Ultra-tolerant mechanism:
$parser->ignoreerrors(1);
$entity = eval { $parser->parse(\*STDIN) };
$error = ($@ || $parser->lasterror);
### Cleanup all files created by the parse:
eval { $entity = $parser->parse(\*STDIN) };
...$parser->filer->purge;
EExxaammpplleess ooff ppaarrsseerr ooppttiioonnss### Automatically attempt to RFC-1522-decode the MIME headers?
$parser->decodeheaders(1); ### default is false
### Parse contained "message/rfc822" objects as nested MIME streams?
$parser->extractnestedmessages(0); ### default is true
### Look for uuencode in "text" messages, and extract it?
$parser->extractuuencode(1); ### default is false
### Should we forgive normally-fatal errors?
$parser->ignoreerrors(0); ### default is true
MMiisscceellllaanneeoouuss eexxaammpplleess### Convert a Mail::Internet object to a MIME::Entity:
@lines = (@{$mail->header}, "\n", @{$mail->body});
$entity = $parser->parsedata(\@lines);
DESCRIPTION
You can inherit from this class to create your own subclasses that parse MIME streams into MIME::Entity objects. PPUUBBLLIICC IINNTTEERRFFAACCEE CCoonnssttrruuccttiioonn new ARGS... Class method. Create a new parser object. Once you do this, you can then set up various parameters before doing the actual parsing. For example:my $parser = new MIME::Parser;
$parser->outputdir("/tmp");
$parser->outputprefix("msg1");
my $entity = $parser->parse(\*STDIN);
Any arguments are passed into "init()". Don't override this in your subclasses; override init() instead. init ARGS...Instance method. Initiallize a new MIME::Parser object. This is
automatically sent to a new object; you may want to override it. If you override this, be sure to invoke the inherited method. initparseInstance method. Invoked automatically whenever one of the top-
level parse() methods is called, to reset the parser to a "ready" state. AAlltteerriinngg hhooww mmeessssaaggeess aarree ppaarrsseedd decodeheaders [YESNO] Instance method. Controls whether the parser will attempt todecode all the MIME headers (as per RFC-1522) the moment it sees
them. TThhiiss iiss nnoott aaddvviissaabbllee ffoorr ttwwoo vveerryy iimmppoorrttaanntt rreeaassoonnss:: +o IItt ssccrreewwss uupp tthhee eexxttrraaccttiioonn ooff iinnffoorrmmaattiioonn ffrroomm MMIIMMEE ffiieellddss.. If you fully decode the headers into bytes, you can inadvertently transform a parseable MIME header like this:Content-type: text/plain; filename="=?ISO-8859-1?Q?Hi=22Ho?="
into unparseable gobbledygook; in this case:Content-type: text/plain; filename="Hi"Ho"
+o IItt iiss iinnffoorrmmaattiioonn-lloossssyy.. An encoded string which contains both
Latin-1 and Cyrillic characters will be turned into a binary
mishmosh which simply can't be rendered.HHiissttoorryy.. This method was once the only out-of-the-box way to deal
with attachments whose filenames had non-ASCII characters.
However, since MIME-tools 5.4xx this is no longer necessary.
PPaarraammeetteerrss.. If YESNO is true, decoding is done. However, you will get a warning unless you use one of the special "true" values: "INEEDTOFIXTHIS" Just shut up and do it. Not recommended. Provided only for those who need to keep old scripts functioning. "IKNOWWHATIAMDOING" Just shut up and do it. Not recommended. Provided for those who REALLY know what they are doing. If YESNO is false (the default), no attempt at decoding will be done. With no argument, just returns the current setting. RReemmeemmbbeerr:: you can always decode the headers after the parsing has completed (see MIME::Head::decode()), or decode the words on demand (see MIME::Words).extractnestedmessages OPTION
Instance method. Some MIME messages will contain a part of type"message/rfc822" ,"message/partial" or "message/external-body":
literally, the text of an embedded mail/news/whatever message. This option controls whether (and how) we parse that embedded message.If the OPTION is false, we treat such a message just as if it were
a "text/plain" document, without attempting to decode its contents.If the OPTION is true (the default), the body of the
"message/rfc822" or "message/partial" part is parsed by this parser, creating an entity object. What happens then is determinedby the actual OPTION:
NEST or 1 The default setting. The contained message becomes the sole "part" of the "message/rfc822" entity (as if the containing message were a special kind of "multipart" message). You canrecover the sub-entity by invoking the parts() method on the
"message/rfc822" entity. REPLACE The contained message replaces the "message/rfc822" entity, as though the "message/rfc822" "container" never existed. WWaarrnniinngg:: notice that, with this option, all the header information in the "message/rfc822" header is lost. This mightseriously bother you if you're dealing with a top-level
message, and you've just lost the sender's address and thesubject line. ":-/".
Thanks to Andreas Koenig for suggesting this method. extractuuencode [YESNO] Instance method. If set true, then whenever we are confronted witha message whose effective content-type is "text/plain" and whose
encoding is 7bit/8bit/binary, we scan the encoded body to see if it contains uuencoded data (generally given away by a "begin XXX" line). If it does, we explode the uuencoded message into a multipart, where the text before the first "begin XXX" becomes the first part, and all "begin...end" sections following become the subsequent parts. The filename (if given) is accessible through the normal means. ignoreerrors [YESNO] Instance method. Controls whether the parser will attempt toignore normally-fatal errors, treating them as warnings and
continuing with the parse. If YESNO is true (the default), many syntax errors are tolerated. If YESNO is false, fatal errors throw exceptions. With no argument, just returns the current setting. decodebodies [YESNO] Instance method. Controls whether the parser should decode entity bodies or not. If this is set to a false value (default is true),all entity bodies will be kept as-is in the original content-
transfer encoding. To prevent double encoding on the output sideMIME::Body->isencoded is set, which tells MIME::Body not to encode
the data again, if encoded data was requested. This is in particular useful, when it's important that the content mmuusstt nnoott be modified, e.g. if you want to calculate OpenPGP signatures from it. WWAARRNNIINNGG: the semantics change significantly if you parse MIME messages with this option set, because MIME::Entity resp. MIME::Body *always* see encoded data now, while the default behaviour is working with *decoded* data (and encoding it only if you request it). You need to decode the data yourself, if you want to have it decoded. So use this option only if you exactly know, what you're doing, and that you're sure, that you really need it. PPaarrssiinngg aann iinnppuutt ssoouurrccee parsedata DATA Instance method. Parse a MIME message that's already in core. You may supply the DATA in any of a number of ways... +o AA ssccaallaarr which holds the message. +o AA rreeff ttoo aa ssccaallaarr which holds the message. This is an efficiency hack. +o AA rreeff ttoo aann aarrrraayy ooff ssccaallaarrss.. They are treated as a stream which (conceptually) consists of simply concatenating the scalars. Returns the parsed MIME::Entity on success. parse INSTREAMInstance method. Takes a MIME-stream and splits it into its
component entities. The INSTREAM can be given as a readable FileHandle, an IO::File, a globref filehandle (like "\*STDIN"), or as any blessed object conforming to the IO:: interface (which minimally implements getline() and read()). Returns the parsed MIME::Entity on success. Throws exception on failure. If the message contained too many parts (as set by maxparts), returns undef. parseopen EXPRInstance method. Convenience front-end onto "parse()". Simply
give this method any expression that may be sent as the second argument to open() to open a filehandle for reading. Returns the parsed MIME::Entity on success. Throws exception on failure. parsetwo HEADFILE, BODYFILEInstance method. Convenience front-end onto "parseopen()",
intended for programs running under mail-handlers like ddeelliivveerr,
which splits the incoming mail message into a header file and a body file. Simply give this method the paths to the respective files. WWaarrnniinngg:: it is assumed that, once the files are cat'ed together, there will be a blank line separating the head part and the body part. WWaarrnniinngg:: new implementation slurps files into line array for portability, instead of using 'cat'. May be an issue if your messages are large. Returns the parsed MIME::Entity on success. Throws exception on failure. SSppeecciiffyyiinngg oouuttppuutt ddeessttiinnaattiioonnWWaarrnniinngg:: in 5.212 and before, this was done by methods of MIME::Parser.
However, since many users have requested fine-tuned control over how
this is done, the logic has been split off from the parser into its ownclass, MIME::Parser::Filer Every MIME::Parser maintains an instance of
a MIME::Parser::Filer subclass to manage disk output (see
MIME::Parser::Filer for details.)
The benefit to this is that the MIME::Parser code won't be confounded
with a lot of garbage related to disk output. The drawback is that the way you override the default behavior will change.For now, all the normal public-interface methods are still provided,
but many are only stubs which create or delegate to the underlyingMIME::Parser::Filer object.
filer [FILER] Instance method. Get/set the FILER object used to manage the output of files to disk. This will be some subclass ofMIME::Parser::Filer.
outputdir DIRECTORY Instance method. Causes messages to be filed directly into the given DIRECTORY. It does this by setting the underlying filer() toa new instance of MIME::Parser::FileInto, and passing the arguments
into that class' new() method. NNoottee:: Since this method replaces the underlying filer, you must invoke it before doing changing any attributes of the filer, like the output prefix; otherwise those changes will be lost. outputunder BASEDIR, OPTS... Instance method. Causes messages to be filed directly into subdirectories of the given BASEDIR, one subdirectory per message. It does this by setting the underlying filer() to a new instance ofMIME::Parser::FileUnder, and passing the arguments into that class'
new() method. NNoottee:: Since this method replaces the underlying filer, you must invoke it before doing changing any attributes of the filer, like the output prefix; otherwise those changes will be lost. outputpath HEAD Instance method, DEPRECATED. Given a MIME head for a file to be extracted, come up with a good output pathname for the extracted file. Identical to the preferred form:$parser->filer->outputpath(...args...);
We just delegate this to the underlying filer() object. outputprefix [PREFIX] Instance method, DEPRECATED. Get/set the short string that allfilenames for extracted body-parts will begin with (assuming that
there is no better "recommended filename"). Identical to the preferred form:$parser->filer->outputprefix(...args...);
We just delegate this to the underlying filer() object.evilfilename NAME
Instance method, DEPRECATED. Identical to the preferred form:$parser->filer->evilfilename(...args...);
We just delegate this to the underlying filer() object. maxparts NUM Instance method. Limits the number of MIME parts we will parse. Normally, instances of this class parse a message to the bitter end. Messages with many MIME parts can cause excessive memory consumption. If you invoke this method, parsing will abort with a die() if a message contains more than NUM parts.If NUM is set to -1 (the default), then no maximum limit is
enforced. With no argument, returns the current setting as an integer outputtocore YESNO Instance method. Normally, instances of this class output all their decoded body data to disk files (via MIME::Body::File). However, you can change this behaviour by invoking this method before parsing: If YESNO is false (the default), then all body data goes to disk files.If YESNO is true, then all body data goes to in-core data
structures This is a little risky (what if someone emails you an MPEG or a tar file, hmmm?) but people seem to want this bit ofnoose-shaped rope, so I'm providing it. Note that setting this
attribute true does not mean that parser-internal temporary files
are avoided! Use tmptocore() for that. With no argument, returns the current setting as a boolean. tmprecycling [YESNO] Instance method. Normally, tmpfiles are created when needed during parsing, and destroyed automatically when they go out of scope. But for efficiency, you might prefer for your parser to attempt to rewind and reuse the same file until the parser itself is destroyed. If YESNO is true (the default), we allow recycling; tmpfiles persist until the parser itself is destroyed. If YESNO is false, we do not allow recycling; tmpfiles persist only as long as they are needed during the parse. With no argument, just returns the current setting. tmptocore [YESNO] Instance method. Should newtmpfile() create real temp files, oruse fake in-core ones? Normally we allow the creation of temporary
disk files, since this allows us to handle huge attachments even when core is limited.If YESNO is true, we implement newtmpfile() via in-core handles.
If YESNO is false (the default), we use real tmpfiles. With no argument, just returns the current setting. useinnerfiles [YESNO] Instance method. If you are parsing from a handle which supports seek() and tell(), then we can avoid tmpfiles completely by using IO::InnerFile, if so desired: basically, we simulate a temporaryfile via pointers to virtual start- and end-positions in the input
stream. If YESNO is false (the default), then we will not use IO::InnerFile. If YESNO is true, we use IO::InnerFile if we can. With no argument, just returns the current setting. NNoottee:: inner files are slower than real tmpfiles, but possiblyfaster than in-core tmpfiles... so your choice for this option will
probably depend on your choice for tmptocore() and the kind of input streams you are parsing. SSppeecciiffyyiinngg ccllaasssseess ttoo bbee iinnssttaannttiiaatteedd interface ROLE,[VALUE] Instance method. During parsing, the parser normally creates instances of certain classes, like MIME::Entity. However, you may want to create a parser subclass that uses your own experimental head, entity, etc. classes (for example, your "head" class mayprovide some additional MIME-field-oriented methods).
If so, then this is the method that your subclass should invoke during init. Use it like this: package MyParser;@ISA = qw(MIME::Parser);
... sub init {my $self = shift;
$self->SUPER::init(@); ### do my parent's init
$self->interface(ENTITYCLASS => 'MIME::MyEntity');
$self->interface(HEADCLASS => 'MIME::MyHead');
$self; ### return
} With no VALUE, returns the VALUE currently associated with that ROLE. newbodyfor HEAD Instance method. Based on the HEAD of a part we are parsing, return a new body object (any desirable subclass of MIME::Body) for receiving that part's data. If you set the "outputtocore" option to false before parsing (the default), then we call "outputpath()" and create a new MIME::Body::File on that filename. If you set the "outputtocore" option to true before parsing, then you get a MIME::Body::InCore instead. If you want the parser to do something else entirely, you can override this method in a subclass. newtmpfile [RECYCLE] Instance method. Return an IO handle to be used to hold temporary data during a parse. The default uses the standardIO::File->newtmpfile() method unless tmptocore() dictates
otherwise, but you can override this. You shouldn't need to. If you do override this, make certain that the object you return is set for binmode(), and is able to handle the following methods: read(BUF, NBYTES) getline() getlines() print(@ARGS) flush() seek(0, 0) Fatal exception if the stream could not be established. If RECYCLE is given, it is an object returned by a previous invocation of this method; to recycle it, this method must effectively rewind and truncate it, and return the same object. If you don't want to support recycling, just ignore it and always return a new object. PPaarrssee rreessuullttss aanndd eerrrroorr rreeccoovveerryy lasterror Instance method. Return the error (if any) that we ignored in the last parse. lastheadInstance method. Return the top-level MIME header of the last
stream we attempted to parse. This is useful for replying to people who sent us bad MIME messages.### Parse an input stream:
eval { $entity = $parser->parse(\*STDIN) };
if (!$entity) { ### parse failed!
my $decapitated = $parser->lasthead;
... } results Instance method. Return an object containing lots of info from the last entity parsed. This will be an instance of classMIME::Parser::Results.
OOPPTTIIMMIIZZIINNGG YYOOUURR PPAARRSSEERR MMaaxxiimmiizziinngg ssppeeeedd Optimum input mechanisms: parse() YES (if you give it a globref or a subclass of IO::File) parseopen() YES parsedata() NO (see below) parsetwo() NO (see below) Optimum settings: decodeheaders() *** (no real difference; 0 is slightly faster) extractnestedmessages() 0 (may be slightly faster, but in general you want it set to 1) outputtocore() 0 (will be MUCH faster) tmprecycling() 1? (probably, but should be investigated) tmptocore() 0 (will be MUCH faster) useinnerfiles() 0 (if tmptocore() is 0; use 1 otherwise)FFiillee II//OO iiss mmuucchh ffaasstteerr tthhaann iinn-ccoorree II//OO.. Although it seems like
slurping a message into core and processing it in-core should be
faster... it isn't. Reason: Perl's filehandle-based I/O translates
directly into native operating-system calls, whereas the in-core I/O is
implemented in Perl.IInnnneerr ffiilleess aarree sslloowweerr tthhaann rreeaall ttmmppffiilleess,, bbuutt ffaasstteerr tthhaann iinn-ccoorree
oonneess.. If speed is your concern, that's why you should set useinnerfiles(true) if you set tmptocore(true): so that we canbypass the slow in-core tmpfiles if the input stream permits.
NNaattiivvee II//OO iiss mmuucchh ffaasstteerr tthhaann oobbjjeecctt-oorriieenntteedd II//OO.. It's much faster
to use <$foo> than $foo->getline. For backwards compatibilty, this
module must continue to use object-oriented I/O in most places, but if
you use parse() with a "real" filehandle (string, globref, or subclassof IO::File) then MIME::Parser is able to perform some crucial
optimizations. The parsetwo() call is very inefficient. urnl ti i js afront-end onto parsedata(). If your OS supports it, you're far better
off doing something like:$parser->parseopen("/bin/cat msg.head msg.body |");
MMiinniimmiizziinngg mmeemmoorryy Optimum input mechanisms: parse() YES parseopen() YESparsedata() NO (in-core I/O will burn core)
parsetwo() NO (in-core I/O will burn core)
Optimum settings: decodeheaders() *** (no real difference) extractnestedmessages() *** (no real difference) outputtocore() 0 (will use MUCH less memory) tmprecycling() 0? (promotes faster GC if tmptocore is 1) tmptocore() 0 (will use MUCH less memory) useinnerfiles() *** (no real difference, but set it to 1 if you *must* have tmptocore set to 1,so that you avoid in-core tmpfiles)
MMaaxxiimmiizziinngg ttoolleerraannccee ooff bbaadd MMIIMMEE Optimum input mechanisms: parse() *** (doesn't matter) parseopen() *** (doesn't matter) parsedata() *** (doesn't matter) parsetwo() *** (doesn't matter) Optimum settings: decodeheaders() 0 (sidesteps problem of bad hdr encodings) extractnestedmessages() 0 (sidesteps problems of bad nested messages, but often you want it set to 1 anyway). outputtocore() *** (doesn't matter) tmprecycling() *** (doesn't matter) tmptocore() *** (doesn't matter) useinnerfiles() *** (doesn't matter)AAvvooiiddiinngg ddiisskk-bbaasseedd tteemmppoorraarryy ffiilleess
Optimum input mechanisms: parse() YES (if you give it a seekable handle) parseopen() YES (becomes a seekable handle) parsedata() NO (unless you set tmptocore(1)) parsetwo() NO (unless you set tmptocore(1)) Optimum settings: decodeheaders() *** (doesn't matter) extractnestedmessages() *** (doesn't matter) outputtocore() *** (doesn't matter) tmprecycling 1 (restricts created files to 1 per parser) tmptocore() 1 useinnerfiles() 1 IIff wwee ccaann uussee tthheemm,, iinnnneerr ffiilleess aavvooiidd mmoosstt ttmmppffiilleess.. If you parse froma seekable-and-tellable filehandle, then the internal
processtobound() doesn't need to extract each part into a temporary buffer; it can use IO::InnerFile (wwaarrnniinngg:: this will slow down the parsing of messages with large attachments). YYoouu ccaann vveettoo ttmmppffiilleess eennttiirreellyy.. If you might not be parsing from aseekable-and-tellable filehandle, you can set tmptocore() true: this
will always use in-core I/O for the buffering (wwaarrnniinngg:: this will slow
down the parsing of messages with large attachments). FFiinnaall rreessoorrtt.. You can always override newtmpfile() in a subclass. WWAARRNNIINNGGSSMultipart messages are always read line-by-line
Multipart document parts are read line-by-line, so that the
encapsulation boundaries may easily be detected. However, bad MIME composition agents (for example, naive CGI scripts) might return multipart documents where the parts are, say, unencoded bitmap files... and, consequently, where such "lines" might be veeeeeeeeery long indeed. A better solution for this case would be to set up some form of state machine for input processing. This will be left for future versions. Multipart parts read into temp files before decoding In my original implementation, the MIME::Decoder classes had to be aware of encapsulation boundaries in multipart MIME documents.While this decode-while-parsing approach obviated the need for
temporary files, it resulted in inflexible and complex decoder implementations. The revised implementation uses a temporary file (a la "tmpfile()") during parsing to hold the encoded portion of the current MIME document or part. This file is deleted automatically after the current part is decoded and the data is written to the "body stream" object; you'll never see it, and should never need to worry about it.Some folks have asked for the ability to bypass this temp-file
mechanism, I suppose because they assume it would slow down theirapplication. I considered accomodating this wish, but the temp-
file approach solves a lot of thorny problems in parsing, and it also protects against hidden bugs in user applications (what if you've directed the encoded part into a scalar, and someone unexpectedly sends you a 6 MB tar file?). Finally, I'm just notconviced that the temp-file use adds significant overhead.
Fuzzing of CRLF and newline on inputRFC-1521 dictates that MIME streams have lines terminated by CRLF
("\r\n"). However, it is extremely likely that folks will want to parse MIME streams where each line ends in the local newline character "\n" instead. An attempt has been made to allow the parser to handle both CRLFand newline-terminated input.
Fuzzing of CRLF and newline on output The "7bit" and "8bit" decoders will decode both a "\n" and a "\r\n"end-of-line sequence into a "\n".
The "binary" decoder (default if no encoding specified) still outputs stuff verbatim... so a MIME message with CRLFs and no explicit encoding will be output as a text file that, on many systems, will have an annoying ^M at the end of each line... but this is as it should be. Inability to handle multipart boundaries that contain newlines First, let's get something straight: this is an evil, EVILpractice, and is incompatible with RFC-1521... hence, it's not
valid MIME. If your mailer creates multipart boundary strings that contain newlines when they appear in the message body, give it two weeks notice and find another one. If your mail robot receives MIME mail like this, regard it as syntactically incorrect MIME, which it is.Why do I say that? Well, in RFC-1521, the syntax of a boundary is
given quite clearly: boundary := 0*69bcharsnospace bchars := bcharsnospace / " " bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"" / "," / "-" / "." / "/" / ":" / "=" / "?"
All of which means that a valid boundary string cannot have newlines in it, and any newlines in such a string in the message header are expected to be solely the result of folding the string(i.e., inserting to-be-removed newlines for readability and line-
shortening only).Yet, there is at least one brain-damaged user agent out there that
composes mail like this:MIME-Version: 1.0
Content-type: multipart/mixed; boundary="--ABC-
123--"
Subject: Hi... I'm a dork! This is a multipart MIME message (yeah, right...)--ABC-
123--
Hi there! We have got to discourage practices like this (and the recent file upload idiocy where binary files that are part of a multipart MIMEmessage aren't base64-encoded) if we want MIME to stay relatively
simple, and MIME parsers to be relatively robust. Thanks to Andreas Koenig for bringing a baaaaaaaaad user agent to my attention. AUTHOR Eryq (eryq@zeegee.com), ZeeGee Software Inc (http://www.zeegee.com). David F. 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. VVEERRSSIIOONN$Revision: 1.20 $ $Date: 2006/03/17 21:03:23 $
perl v5.8.8 2006-03-17 MIME::Parser(3)