1MIME::Tools(3) User Contributed Perl Documentation MIME::Tools(3)
2
6 MIME-tools - modules for parsing (and creating!) MIME entities
7
9 Here's some pretty basic code for parsing a MIME message, and out‐
10 putting its decoded components to a given directory:
11 use MIME::Parser;
13 ### Create parser, and set some parsing options:
15 my $parser = new MIME::Parser;
16 $parser->output_under("$ENV{HOME}/mimemail");
17 ### Parse input:
19 $entity = $parser->parse(\*STDIN) or die "parse failed\n";
20 ### Take a look at the top-level entity (and any parts it has):
22 $entity->dump_skeleton;
23 Here's some code which composes and sends a MIME message containing
25 three parts: a text file, an attached GIF, and some more text:
26 use MIME::Entity;
28 ### Create the top-level, and set up the mail headers:
30 $top = MIME::Entity->build(Type =>"multipart/mixed",
31 From => "me\@myhost.com",
32 To => "you\@yourhost.com",
33 Subject => "Hello, nurse!");
34 ### Part #1: a simple text document:
36 $top->attach(Path=>"./testin/short.txt");
37 ### Part #2: a GIF file:
39 $top->attach(Path => "./docs/mime-sm.gif",
40 Type => "image/gif",
41 Encoding => "base64");
42 ### Part #3: some literal text:
44 $top->attach(Data=>$message);
45 ### Send it:
47 open MAIL, "⎪ /usr/lib/sendmail -t -oi -oem" or die "open: $!";
48 $top->print(\*MAIL);
49 close MAIL;
50 For more examples, look at the scripts in the examples directory of the
52 MIME-tools distribution.
53
55 MIME-tools is a collection of Perl5 MIME:: modules for parsing, decod‐
56 ing, and generating single- or multipart (even nested multipart) MIME
57 messages. (Yes, kids, that means you can send messages with attached
58 GIF files).
59
61 You will need the following installed on your system:
62 File::Path
64 File::Spec
65 IPC::Open2 (optional)
66 IO::Scalar, ... from the IO-stringy distribution
67 MIME::Base64
68 MIME::QuotedPrint
69 Net::SMTP
70 Mail::Internet, ... from the MailTools distribution.
71 See the Makefile.PL in your distribution for the most-comprehensive
73 list of prerequisite modules and their version numbers.
74
76 Overview of the classes
77 Here are the classes you'll generally be dealing with directly:
79 (START HERE) results() .-----------------.
81 \ .-------->⎪ MIME:: ⎪
82 .-----------. / ⎪ Parser::Results ⎪
83 ⎪ MIME:: ⎪--' `-----------------'
84 ⎪ Parser ⎪--. .-----------------.
85 `-----------' \ filer() ⎪ MIME:: ⎪
86 ⎪ parse() `-------->⎪ Parser::Filer ⎪
87 ⎪ gives you `-----------------'
88 ⎪ a... ⎪ output_path()
89 ⎪ ⎪ determines
90 ⎪ ⎪ path() of...
91 ⎪ head() .--------. ⎪
92 ⎪ returns... ⎪ MIME:: ⎪ get() ⎪
93 V .-------->⎪ Head ⎪ etc... ⎪
94 .--------./ `--------' ⎪
95 .---> ⎪ MIME:: ⎪ ⎪
96 `-----⎪ Entity ⎪ .--------. ⎪
97 parts() `--------'\ ⎪ MIME:: ⎪ /
98 returns `-------->⎪ Body ⎪<---------'
99 sub-entities bodyhandle() `--------'
100 (if any) returns... ⎪ open()
101 ⎪ returns...
102 ⎪
103 V
104 .--------. read()
105 ⎪ IO:: ⎪ getline()
106 ⎪ Handle ⎪ print()
107 `--------' etc...
108 To illustrate, parsing works this way:
110 · The "parser" parses the MIME stream. A parser is an instance of
112 "MIME::Parser". You hand it an input stream (like a filehandle) to
113 parse a message from: if the parse is successful, the result is an
114 "entity".
115 · A parsed message is represented by an "entity". An entity is an
117 instance of "MIME::Entity" (a subclass of "Mail::Internet"). If
118 the message had "parts" (e.g., attachments), then those parts are
119 "entities" as well, contained inside the top-level entity. Each
120 entity has a "head" and a "body".
121 · The entity's "head" contains information about the message. A
123 "head" is an instance of "MIME::Head" (a subclass of
124 "Mail::Header"). It contains information from the message header:
125 content type, sender, subject line, etc.
126 · The entity's "body" knows where the message data is. You can ask
128 to "open" this data source for reading or writing, and you will get
129 back an "I/O handle".
130 · You can open() a "body" and get an "I/O handle" to read/write mes‐
132 sage data. This handle is an object that is basically like an
133 IO::Handle or a FileHandle... it can be any class, so long as it
134 supports a small, standard set of methods for reading from or writ‐
135 ing to the underlying data source.
136 A typical multipart message containing two parts -- a textual greeting
138 and an "attached" GIF file -- would be a tree of MIME::Entity objects,
139 each of which would have its own MIME::Head. Like this:
140 .--------.
142 ⎪ MIME:: ⎪ Content-type: multipart/mixed
143 ⎪ Entity ⎪ Subject: Happy Samhaine!
144 `--------'
145 ⎪
146 `----.
147 parts ⎪
148 ⎪ .--------.
149 ⎪---⎪ MIME:: ⎪ Content-type: text/plain; charset=us-ascii
150 ⎪ ⎪ Entity ⎪ Content-transfer-encoding: 7bit
151 ⎪ `--------'
152 ⎪ .--------.
153 ⎪---⎪ MIME:: ⎪ Content-type: image/gif
154 ⎪ Entity ⎪ Content-transfer-encoding: base64
155 `--------' Content-disposition: inline;
156 filename="hs.gif"
157 Parsing messages
159 You usually start by creating an instance of MIME::Parser and setting
161 up certain parsing parameters: what directory to save extracted files
162 to, how to name the files, etc.
163 You then give that instance a readable filehandle on which waits a MIME
165 message. If all goes well, you will get back a MIME::Entity object (a
166 subclass of Mail::Internet), which consists of...
167 · A MIME::Head (a subclass of Mail::Header) which holds the MIME
169 header data.
170 · A MIME::Body, which is a object that knows where the body data is.
172 You ask this object to "open" itself for reading, and it will hand
173 you back an "I/O handle" for reading the data: this is a FileHan‐
174 dle-like object, and could be of any class, so long as it conforms
175 to a subset of the IO::Handle interface.
176 If the original message was a multipart document, the MIME::Entity
178 object will have a non-empty list of "parts", each of which is in turn
179 a MIME::Entity (which might also be a multipart entity, etc, etc...).
180 Internally, the parser (in MIME::Parser) asks for instances of
182 MIME::Decoder whenever it needs to decode an encoded file.
183 MIME::Decoder has a mapping from supported encodings (e.g., 'base64')
184 to classes whose instances can decode them. You can add to this map‐
185 ping to try out new/experiment encodings. You can also use
186 MIME::Decoder by itself.
187 Composing messages
189 All message composition is done via the MIME::Entity class. For sin‐
191 gle-part messages, you can use the MIME::Entity/build constructor to
192 create MIME entities very easily.
193 For multipart messages, you can start by creating a top-level "multi‐
195 part" entity with MIME::Entity::build(), and then use the similar
196 MIME::Entity::attach() method to attach parts to that message. Please
197 note: what most people think of as "a text message with an attached GIF
198 file" is really a multipart message with 2 parts: the first being the
199 text message, and the second being the GIF file.
200 When building MIME a entity, you'll have to provide two very important
202 pieces of information: the content type and the content transfer encod‐
203 ing. The type is usually easy, as it is directly determined by the
204 file format; e.g., an HTML file is "text/html". The encoding, however,
205 is trickier... for example, some HTML files are "7bit"-compliant, but
206 others might have very long lines and would need to be sent
207 "quoted-printable" for reliability.
208 See the section on encoding/decoding for more details, as well as "A
210 MIME PRIMER".
211 Sending email
213 Since MIME::Entity inherits directly from Mail::Internet, you can use
215 the normal Mail::Internet mechanisms to send email. For example,
216 $entity->smtpsend;
218 Encoding/decoding support
220 The MIME::Decoder class can be used to encode as well; this is done
222 when printing MIME entities. All the standard encodings are supported
223 (see "A MIME PRIMER" for details):
224 Encoding: ⎪ Normally used when message contents are:
226 -------------------------------------------------------------------
227 7bit ⎪ 7-bit data with under 1000 chars/line, or multipart.
228 8bit ⎪ 8-bit data with under 1000 chars/line.
229 binary ⎪ 8-bit data with some long lines (or no line breaks).
230 quoted-printable ⎪ Text files with some 8-bit chars (e.g., Latin-1 text).
231 base64 ⎪ Binary files.
232 Which encoding you choose for a given document depends largely on (1)
234 what you know about the document's contents (text vs binary), and (2)
235 whether you need the resulting message to have a reliable encoding for
236 7-bit Internet email transport.
237 In general, only "quoted-printable" and "base64" guarantee reliable
239 transport of all data; the other three "no-encoding" encodings simply
240 pass the data through, and are only reliable if that data is 7bit ASCII
241 with under 1000 characters per line, and has no conflicts with the mul‐
242 tipart boundaries.
243 I've considered making it so that the content-type and encoding can be
245 automatically inferred from the file's path, but that seems to be ask‐
246 ing for trouble... or at least, for Mail::Cap...
247 Message-logging
249 MIME-tools is a large and complex toolkit which tries to deal with a
251 wide variety of external input. It's sometimes helpful to see what's
252 really going on behind the scenes. There are several kinds of messages
253 logged by the toolkit itself:
254 Debug messages
256 These are printed directly to the STDERR, with a prefix of
257 "MIME-tools: debug".
258 Debug message are only logged if you have turned "debugging" on in
260 the MIME::Tools configuration.
261 Warning messages
263 These are logged by the standard Perl warn() mechanism to indicate
264 an unusual situation. They all have a prefix of "MIME-tools: warn‐
265 ing".
266 Warning messages are only logged if $^W is set true and MIME::Tools
268 is not configured to be "quiet".
269 Error messages
271 These are logged by the standard Perl warn() mechanism to indicate
272 that something actually failed. They all have a prefix of
273 "MIME-tools: error".
274 Error messages are only logged if $^W is set true and MIME::Tools
276 is not configured to be "quiet".
277 Usage messages
279 Unlike "typical" warnings above, which warn about problems process‐
280 ing data, usage-warnings are for alerting developers of deprecated
281 methods and suspicious invocations.
282 Usage messages are currently only logged if $^W is set true and
284 MIME::Tools is not configured to be "quiet".
285 When a MIME::Parser (or one of its internal helper classes) wants to
287 report a message, it generally does so by recording the message to the
288 MIME::Parser::Results object immediately before invoking the appropri‐
289 ate function above. That means each parsing run has its own trace-log
290 which can be examined for problems.
291 Configuring the toolkit
293 If you want to tweak the way this toolkit works (for example, to turn
295 on debugging), use the routines in the MIME::Tools module.
296 debugging
298 Turn debugging on or off. Default is false (off).
299 MIME::Tools->debugging(1);
301 quiet
303 Turn the reporting of warning/error messages on or off. Default is
304 true, meaning that these message are silenced.
305 MIME::Tools->quiet(1);
307 version
309 Return the toolkit version.
310 print MIME::Tools->version, "\n";
312
314 Take a look at the examples
315 The MIME-Tools distribution comes with an "examples" directory. The
317 scripts in there are basically just tossed-together, but they'll give
318 you some ideas of how to use the parser.
319 Run with warnings enabled
321 Always run your Perl script with "-w". If you see a warning about a
323 deprecated method, change your code ASAP. This will ease upgrades
324 tremendously.
325 Avoid non-standard encodings
327 Don't try to MIME-encode using the non-standard MIME encodings. It's
329 just not a good practice if you want people to be able to read your
330 messages.
331 Plan for thrown exceptions
333 For example, if your mail-handling code absolutely must not die, then
335 perform mail parsing like this:
336 $entity = eval { $parser->parse(\*INPUT) };
338 Parsing is a complex process, and some components may throw exceptions
340 if seriously-bad things happen. Since "seriously-bad" is in the eye of
341 the beholder, you're better off catching possible exceptions instead of
342 asking me to propagate "undef" up the stack. Use of exceptions in re‐
343 usable modules is one of those religious issues we're never all going
344 to agree upon; thankfully, that's what "eval{}" is good for.
345 Check the parser results for warnings/errors
347 As of 5.3xx, the parser tries extremely hard to give you a
349 MIME::Entity. If there were any problems, it logs warnings/errors to
350 the underlying "results" object (see MIME::Parser::Results). Look at
351 that object after each parse. Print out the warnings and errors, espe‐
352 cially if messages don't parse the way you thought they would.
353 Don't plan on printing exactly what you parsed!
355 Parsing is a (slightly) lossy operation. Because of things like ambi‐
357 guities in base64-encoding, the following is not going to spit out its
358 input unchanged in all cases:
359 $entity = $parser->parse(\*STDIN);
361 $entity->print(\*STDOUT);
362 If you're using MIME::Tools to process email, remember to save the data
364 you parse if you want to send it on unchanged. This is vital for
365 things like PGP-signed email.
366 Understand how international characters are represented
368 The MIME standard allows for text strings in headers to contain charac‐
370 ters from any character set, by using special sequences which look like
371 this:
372 =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?=
374 To be consistent with the existing Mail::Field classes, MIME::Tools
376 does not automatically unencode these strings, since doing so would
377 lose the character-set information and interfere with the parsing of
378 fields (see "decode_headers" in MIME::Parser for a full explanation).
379 That means you should be prepared to deal with these encoded strings.
380 The most common question then is, how do I decode these encoded
382 strings? The answer depends on what you want to decode them to: ASCII,
383 Latin1, UTF-8, etc. Be aware that your "target" representation may not
384 support all possible character sets you might encounter; for example,
385 Latin1 (ISO-8859-1) has no way of representing Big5 (Chinese) charac‐
386 ters. A common practice is to represent "untranslateable" characters
387 as "?"s, or to ignore them completely.
388 To unencode the strings into some of the more-popular Western byte rep‐
390 resentations (e.g., Latin1, Latin2, etc.), you can use the decoders in
391 MIME::WordDecoder (see MIME::WordDecoder). The simplest way is by
392 using "unmime()", a function wrapped around your "default" decoder, as
393 follows:
394 use MIME::WordDecoder;
396 ...
397 $subject = unmime $entity->head->get('subject');
398 One place this is done automatically is in extracting the recommended
400 filename for a part while parsing. That's why you should start by set‐
401 ting up the best "default" decoder if the default target of Latin1
402 isn't to your liking.
403
405 Fuzzing of CRLF and newline on input
406 RFC-1521 dictates that MIME streams have lines terminated by CRLF
408 ("\r\n"). However, it is extremely likely that folks will want to
409 parse MIME streams where each line ends in the local newline character
410 "\n" instead.
411 An attempt has been made to allow the parser to handle both CRLF and
413 newline-terminated input.
414 Fuzzing of CRLF and newline when decoding
416 The "7bit" and "8bit" decoders will decode both a "\n" and a "\r\n"
418 end-of-line sequence into a "\n".
419 The "binary" decoder (default if no encoding specified) still outputs
421 stuff verbatim... so a MIME message with CRLFs and no explicit encoding
422 will be output as a text file that, on many systems, will have an
423 annoying ^M at the end of each line... but this is as it should be.
424 Fuzzing of CRLF and newline when encoding/composing
426 All encoders currently output the end-of-line sequence as a "\n", with
428 the assumption that the local mail agent will perform the conversion
429 from newline to CRLF when sending the mail. However, there probably
430 should be an option to output CRLF as per RFC-1521.
431 Inability to handle multipart boundaries with embedded newlines
433 Let's get something straight: this is an evil, EVIL practice. If your
435 mailer creates multipart boundary strings that contain newlines, give
436 it two weeks notice and find another one. If your mail robot receives
437 MIME mail like this, regard it as syntactically incorrect, which it is.
438 Ignoring non-header headers
440 People like to hand the parser raw messages straight from POP3 or from
442 a mailbox. There is often predictable non-header information in front
443 of the real headers; e.g., the initial "From" line in the following
444 message:
445 From - Wed Mar 22 02:13:18 2000
447 Return-Path: <eryq@zeegee.com>
448 Subject: Hello
449 The parser simply ignores such stuff quietly. Perhaps it shouldn't,
451 but most people seem to want that behavior.
452 Fuzzing of empty multipart preambles
454 Please note that there is currently an ambiguity in the way preambles
456 are parsed in. The following message fragments both are regarded as
457 having an empty preamble (where "\n" indicates a newline character):
458 Content-type: multipart/mixed; boundary="xyz"\n
460 Subject: This message (#1) has an empty preamble\n
461 \n
462 --xyz\n
463 ...
464 Content-type: multipart/mixed; boundary="xyz"\n
466 Subject: This message (#2) also has an empty preamble\n
467 \n
468 \n
469 --xyz\n
470 ...
471 In both cases, the first completely-empty line (after the "Subject")
473 marks the end of the header.
474 But we should clearly ignore the second empty line in message #2, since
476 it fills the role of "the newline which is only there to make sure that
477 the boundary is at the beginning of a line". Such newlines are never
478 part of the content preceding the boundary; thus, there is no preamble
479 "content" in message #2.
480 However, it seems clear that message #1 also has no preamble "content",
482 and is in fact merely a compact representation of an empty preamble.
483 Use of a temp file during parsing
485 Why not do everything in core? Although the amount of core available
487 on even a modest home system continues to grow, the size of attachments
488 continues to grow with it. I wanted to make sure that even users with
489 small systems could deal with decoding multi-megabyte sounds and movie
490 files. That means not being core-bound.
491 As of the released 5.3xx, MIME::Parser gets by with only one temp file
493 open per parser. This temp file provides a sort of infinite scratch
494 space for dealing with the current message part. It's fast and light‐
495 weight, but you should know about it anyway.
496 Why do I assume that MIME objects are email objects?
498 Achim Bohnet once pointed out that MIME headers do nothing more than
500 store a collection of attributes, and thus could be represented as
501 objects which don't inherit from Mail::Header.
502 I agree in principle, but RFC-1521 says otherwise. RFC-1521 [MIME]
504 headers are a syntactic subset of RFC-822 [email] headers. Perhaps a
505 better name for these modules would have been RFC1521:: instead of
506 MIME::, but we're a little beyond that stage now.
507 When I originally wrote these modules for the CPAN, I agonized for a
509 long time about whether or not they really should subclass from
510 Mail::Internet (then at version 1.17). Thanks to Graham Barr, who gra‐
511 ciously evolved MailTools 1.06 to be more MIME-friendly, unification
512 was achieved at MIME-tools release 2.0. The benefits in reuse alone
513 have been substantial.
514
516 So you need to parse (or create) MIME, but you're not quite up on the
517 specifics? No problem...
518 Glossary
520 Here are some definitions adapted from RFC-1521 explaining the termi‐
522 nology we use; each is accompanied by the equivalent in MIME:: module
523 terms...
524 attachment
526 An "attachment" is common slang for any part of a multipart message
527 -- except, perhaps, for the first part, which normally carries a
528 user message describing the attachments that follow (e.g.: "Hey
529 dude, here's that GIF file I promised you.").
530 In our system, an attachment is just a MIME::Entity under the top-
532 level entity, probably one of its parts.
533 body
535 The "body" of an entity is that portion of the entity which follows
536 the header and which contains the real message content. For exam‐
537 ple, if your MIME message has a GIF file attachment, then the body
538 of that attachment is the base64-encoded GIF file itself.
539 A body is represented by an instance of MIME::Body. You get the
541 body of an entity by sending it a bodyhandle() message.
542 body part
544 One of the parts of the body of a multipart /entity. A body part
545 has a /header and a /body, so it makes sense to speak about the
546 body of a body part.
547 Since a body part is just a kind of entity, it's represented by an
549 instance of MIME::Entity.
550 entity
552 An "entity" means either a /message or a /body part. All entities
553 have a /header and a /body.
554 An entity is represented by an instance of MIME::Entity. There are
556 instance methods for recovering the header (a MIME::Head) and the
557 body (a MIME::Body).
558 header
560 This is the top portion of the MIME message, which contains the
561 "Content-type", "Content-transfer-encoding", etc. Every MIME
562 entity has a header, represented by an instance of MIME::Head. You
563 get the header of an entity by sending it a head() message.
564 message
566 A "message" generally means the complete (or "top-level") message
567 being transferred on a network.
568 There currently is no explicit package for "messages"; under
570 MIME::, messages are streams of data which may be read in from
571 files or filehandles. You can think of the MIME::Entity returned
572 by the MIME::Parser as representing the full message.
573 Content types
575 This indicates what kind of data is in the MIME message, usually as
577 majortype/minortype. The standard major types are shown below. A
578 more-comprehensive listing may be found in RFC-2046.
579 application
581 Data which does not fit in any of the other categories, particu‐
582 larly data to be processed by some type of application program.
583 "application/octet-stream", "application/gzip", "application/post‐
584 script"...
585 audio
587 Audio data. "audio/basic"...
588 image
590 Graphics data. "image/gif", "image/jpeg"...
591 message
593 A message, usually another mail or MIME message. "mes‐
594 sage/rfc822"...
595 multipart
597 A message containing other messages. "multipart/mixed", "multi‐
598 part/alternative"...
599 text
601 Textual data, meant for humans to read. "text/plain",
602 "text/html"...
603 video
605 Video or video+audio data. "video/mpeg"...
606 Content transfer encodings
608 This is how the message body is packaged up for safe transit. There
610 are the 5 major MIME encodings. A more-comprehensive listing may be
611 found in RFC-2045.
612 7bit
614 No encoding is done at all. This label simply asserts that no
615 8-bit characters are present, and that lines do not exceed 1000
616 characters in length (including the CRLF).
617 8bit
619 No encoding is done at all. This label simply asserts that the
620 message might contain 8-bit characters, and that lines do not
621 exceed 1000 characters in length (including the CRLF).
622 binary
624 No encoding is done at all. This label simply asserts that the
625 message might contain 8-bit characters, and that lines may exceed
626 1000 characters in length. Such messages are the least likely to
627 get through mail gateways.
628 base64
630 A standard encoding, which maps arbitrary binary data to the 7bit
631 domain. Like "uuencode", but very well-defined. This is how you
632 should send essentially binary information (tar files, GIFs, JPEGs,
633 etc.).
634 quoted-printable
636 A standard encoding, which maps arbitrary line-oriented data to the
637 7bit domain. Useful for encoding messages which are textual in
638 nature, yet which contain non-ASCII characters (e.g., Latin-1,
639 Latin-2, or any other 8-bit alphabet).
640
642 Eryq (eryq@zeegee.com), ZeeGee Software Inc (http://www.zeegee.com).
643 David F. Skoll (dfs@roaringpenguin.com) http://www.roaringpenguin.com
644 Copyright (c) 1998, 1999 by ZeeGee Software Inc (www.zeegee.com).
646 Copyright (c) 2004 by Roaring Penguin Software Inc (www.roaringpen‐
647 guin.com)
648 All rights reserved. This program is free software; you can redis‐
650 tribute it and/or modify it under the same terms as Perl itself. See
651 the COPYING file in the distribution for details.
652
654 Please email me directly with questions/problems (see AUTHOR below).
655 If you want to be placed on an email distribution list (not a mailing
657 list!) for MIME-tools, and receive bug reports, patches, and updates
658 as to when new MIME-tools releases are planned, just email me and say
659 so. If your project is using MIME-tools, it might not be a bad idea to
660 find out about those bugs before they become problems...
661
663 $Revision: 1.15 $
664
666 Version 5.411
667 Regenerated docs. Bug in HTML docs, now all fixed.
668 Version 5.410 (2000/11/23)
670 Better detection of evil filenames. Now we check for filenames
671 which are suspiciously long, and a new MIME::Filer::exorcise_file‐
672 name() method is used to try and remove the evil. Thanks to Jason
673 Haar for the suggestion.
674 Version 5.409 (2000/11/12)
676 Added functionality to MIME::WordDecoder, including support for
677 plain US-ASCII.
678 MIME::Tools::tmpopen() made more flexible. You can now override
680 the tmpfile-opening behavior.
681 Version 5.408 (2000/11/10)
683 Added new Beta unmime() mechanism. See MIME::WordDecoder for full
684 details. Also see "Understand how international characters are
685 represented".
686 Version 5.405 (2000/11/05)
688 Added a purge() that does what people want it to. Now, when a
689 parse finishes and you want to delete everything that was created
690 by it, you can invoke "purge()" on the parser's filer. All
691 files/directories created during the last parse should vanish.
692 Thanks to everyone who complained about MIME::Entity::purge.
693 Version 5.404 (2000/11/04)
695 Added new automatic MIME-decoding of attachment filenames with
696 encoded (non-ASCII) characters. Hopefully this will do more good
697 than harm. The use of MIME::Parser::decode_headers() and
698 MIME::Head::decode() has been deprecated in favor of the new
699 MIME::Words "unmime" mechanism. Please see "unmime" in
700 MIME::Words.
701 Added tolerance for unquoted =?...?= in param values. This is in
703 violation of the RFCs, but then, so are some MUAs. Thanks to desti
704 for bringing this to my attention.
705 Fixed supposedly-bad B-encoding. Thanks to Otto Frost for bringing
707 this to my attention.
708 Version 5.316 (2000/09/21)
710 Increased tolerance in MIME::Parser. Now will ignore bogus POP3
711 "+OK" line before header, as well as bogus mailbox "From " line
712 (both with warnings). Thanks to Antony OSullivan (ajos1) for sug‐
713 gesting this feature.
714 Fixed small epilogue-related bug in MIME::Entity::print_body().
716 Now it only outputs a final newline if the epilogue does not end in
717 one already. Support for checking the preamble/epilogue in regres‐
718 sion tests was also added. Thanks to Lars Hecking for bringing
719 this issue up.
720 Updated documentation. All module manual pages should now direct
722 readers to the main MIME-tools manual page.
723 Version 5.314 (2000/09/06)
725 Fixed Makefile.PL to have less-restrictive requirement for
726 File::Spec (0.6).
727 Version 5.313 (2000/09/05)
729 Fixed nasty bug with evil filenames. Certain evil filenames were
730 getting replaced by internally-generated filenames which were just
731 as evil... ouch! If your parser occasionally throws a fatal excep‐
732 tion with a "write-open" error message, then you have this bug.
733 Thanks to Julian Field and Antony OSullivan (ajos1) for delivering
734 the evidence!
735 Beware the doctor
737 who cures seasonal head cold
738 by killing patient
739 Improved naming of extracted files. If a filename is regarded as
741 evil, we guess that it might just be because of part information,
742 and attempt to find and use the final path element.
743 Simplified message logging and made it more consistent. For
745 details, see "Message-logging".
746 Version 5.312 (2000/09/03)
748 Fixed a Perl 5.7 select() incompatibility which caused "make test"
749 to fail. Thanks to Nick Ing-Simmons for the patch.
750 Version 5.311 (2000/08/16)
752 Blind fix for Win32 uudecoding bug. A missing binmode seems to be
753 the culprit here; let's see if this fixes it. Thanks to ajos1 for
754 finding the culprit!
755 The carriage return
757 thumbs its nose at me, laughing:
758 DOS I/O *still* sucks
759 Version 5.310 (2000/08/15)
761 Fixed a bug in the back-compat output_prefix() method of
762 MIME::Parser. Basically, output prefixes were not being set
763 through this mechanism. Thanks to ajos1 for the alert.
764 shift @_, ### "shift at-underscore"
766 or @_ will have
767 bogus "self" object
768 Added some backcompat methods, like parse_FH(). Thanks (and apolo‐
770 gies) to Alain Kotoujansky.
771 Added filenames-with-spaces support to MIME::Decoder::UU. Thanks
773 to Richard Pun for the suggestion.
774 Version 5.305 (2000/07/20)
776 Added MIME::Entity::parts_DFS as convenient way to "get all parts".
777 Thanks to Xavier Armengou for suggesting this method.
778 Removed the Alpha notice. Still a few features to tweak, but those
780 will be minor.
781 Version 5.303 (2000/07/07)
783 Fixed output bugs in new Filers. Scads of them: bad handling of
784 filename collisions, bad implementation of output_under(), bad
785 linking to results, POD errors, you name it. If this had gone to
786 CPAN, I'd have issued a factory recall. ":-("
787 Errors, like beetles,
789 Multiply ferociously
790 In the small hours
791 Version 5.301 (2000/07/06)
793 READ ME BEFORE UPGRADING PAST THIS POINT! New MIME::Parser::Filer
794 class -- not fully backwards-compatible. In response to demand for
795 more-comprehensive file-output strategies, I have decided that the
796 best thing to do is to split all the file-output logic (out‐
797 put_path(), evil_filename(), etc.) into its own separate class,
798 inheriting from the new MIME::Parser::Filer class. If you override
799 any of the following in a MIME::Parser subclass, you will need to
800 change your code accordingly:
801 evil_filename
803 output_dir
804 output_filename
805 output_path
806 output_prefix
807 output_under
808 My sincere apologies for any inconvenience this will cause, but
810 it's ultimately for the best, and is quite likely the last struc‐
811 tural change to 5.x. Thanks to Tyson Ackland for all the ideas.
812 Incidentally, the new code also fixes a bug where identically-named
813 files in the same message could clobber each other.
814 A message arrives:
816 "Here are three files, all named 'Foo'"
817 Only one survives. :-(
818 Fixed bug in MIME::Words header decoding. Underscores were not
820 being handled properly. Thanks to Dominique Unruh and Doru
821 Petrescu, who independently submitted the same fix within 2 hours
822 of each other, after this bug has lain dormant for months:
823 Two users, same bug,
825 same patch -- mere hours apart:
826 Truly, life is odd.
827 Removed escaping of underscore in regexps. Escaping the underscore
829 (\_) in regexps was sloppy and wrong (escaped metacharacters may
830 include anything in \w), and the newest Perls warn about it.
831 Thanks to David Dyck for bringing this to my attention.
832 What, then, is a word?
834 Some letters, digits, and, yes:
835 Underscores as well
836 Added Force option to MIME::Entity's make_multipart. Thanks to Bob
838 Glickstein for suggesting this.
839 Numerous fixlets to example code. Thanks to Doru Petrescu for
841 these.
842 Added REQUIREMENTS section in docs. Long-overdue. Thanks to Ingo
844 Schmiegel for motivating this.
845 Version 5.211 (2000/06/24)
847 Fixed auto-uudecode bug. Parser was failing with "part did not end
848 with expected boundary" error when uuencoded entity was a sin‐
849 glepart message (ironically, uuencoded parts of multiparts worked
850 fine). Thanks to Michael Mohlere for testing uudecode and finding
851 this.
852 The hurrying bee
854 Flies far for nectar, missing
855 The nearest flowers
856 Say ten thousand times:
858 Complex cases may succeed
859 Where simple ones fail
860 Parse errors now generate warnings. Parser errors now cause
862 warn()s to be generated if they are not turned into fatal excep‐
863 tions. This might be a little redundant, seeing as they are avail‐
864 able in the "results", but parser-warnings already cause warn()s.
865 I can always put in a "quiet" switch if people complain.
866 Miscellaneous cleanup. Documentation of MIME::Parser improved
868 slightly, and a redundant warning was removed.
869 Version 5.210 (2000/06/20)
871 Change in "evil" filename. Made MIME::Parser's evil_filename
872 stricter by having it reject "path" characters: any of '/' '\' ':'
873 '[' ']'.
874 Just as with beauty
876 The eye of the beholder
877 Is where "evil" lives.
878 Documentation fixes. Corrected a number of docs in MIME::Entity
880 which were obsoleted in the transition from 4.x to 5.x. Thanks to
881 Michael Fischer for pointing these out. For this one, a special
882 5-5-5-5 Haiku of anagrams:
883 Documentation
885 in mutant code, O!
886 Edit -- no, CUT! [moan]
887 I meant to un-doc...
888 IO::Lines usage bug fixed. MIME::Entity was missing a "use
890 IO::Lines", which caused an exception when you tried to use the
891 body() method of MIME::Entity. Thanks to Hideyo Imazu and Michael
892 Fischer for pointing this out.
893 Bareword looks fine, but
895 Perl cries: "Whoa there... IO::Lines?
896 Never heard of it."
897 Version 5.209 (2000/06/10)
899 Autodetection of uuencode. You can now tell the parser to hunt for
900 uuencode inside what should be text parts. See extract_uuencode()
901 for full details. Beware: this is largely untested at the moment.
902 Special thanks to Michael Mohlere at ADJE Webmail, who was the
903 first -- and most-insistent -- user to request this feature.
904 Faster parsing. Sped up the MIME::Decoder::NBit decoder quite a
906 bit by using a variant of the chunking trick I used for
907 MIME::Decoder::Base64. I suspect that the same trick (reading a
908 big chunk plus the next line to get a big block of lines) would
909 work with MIME::Decoder::QuotedPrint, but I don't have the time or
910 resources to check that right now (tested contributions would be
911 welcome). NBit encoding is more-conveniently done line-by-line for
912 now, because individual line lengths must be checked.
913 Better use of core. MIME::Body::InCore is now used when you
915 build() an entity with the Data parameter, instead of
916 MIME::Body::Scalar.
917 More documentation on toolkit configuration.
919 Version 5.207 (2000/06/09)
921 Fixed whine() bug in MIME::Parser where the "warning" method
922 whine() was called as a static function instead of invoked as an
923 instance method. Thanks to Todd A. Bradfute for reporting this.
924 A simple warning
926 Invokes method as function:
927 "Warning" makes us die
928 Version 5.206 (2000/06/08)
930 Ahem. Cough cough:
931 Way too many bugs
933 Thus, a self-imposed penance:
934 Write haiku for each
935 Fixed bug in MIME::Parser: the reader was not handling the odd (but
937 legal) case where a multipart boundary is followed by linear white‐
938 space. Thanks to Jon Agnew for reporting this with the RFC cita‐
939 tion.
940 Legal message fails
942 And 'round the globe, thousands cry:
943 READ THE RFC
944 Empty preambles are now handled properly by MIME::Entity when
946 printing: there is now no space between the header-terminator and
947 the initial boundary. Thanks to "sen_ml" for suggesting this.
948 Nature hates vacuum
950 But please refrain from tossing
951 Newlines in the void
952 Started using Benchmark for benchmarking.
954 Version 5.205 (2000/06/06)
956 Added terminating newline to all parser messages, and fixed small
957 parser bug that was dropping parts when errors occurred in certain
958 places.
959 Version 5.203 (2000/06/05)
961 Brand new parser based on new (private) MIME::Parser::Reader and
962 (public) MIME::Parser::Results. Fast and yet simple and very tol‐
963 erant of bad MIME when desired. Message reporting needs some muz‐
964 zling.
965 MIME::Parser now has ignore_errors() set true by default.
967 Version 5.116 (2000/05/26)
969 Removed Tmpfile.t test, which was causing a bogus failure in "make
970 test". Now we require 5.004 for MIME::Parser anyway, so we don't
971 need it. Thanks to Jonathan Cohn for reporting this.
972 Version 5.115 (2000/05/24)
974 Fixed Ref.t bug, and documented how to remove parts from a
975 MIME::Entity.
976 Version 5.114 (2000/05/23)
978 Entity now uses MIME::Lite-style default suggested encoding.
979 More regression test have been added, and the "Size" tests in Ref.t
981 are skipped for text document (due to CRLF differences between
982 platforms).
983 Version 5.113 (2000/05/21)
985 Major speed and structural improvements to the parser.
986 Major, MAJOR thanks to Noel Burton-Krahn, Jeremy Gilbert,
987 and Doru Petrescu for all the patches, benchmarking,
988 and Beta-testing!
989 Convenient new one-directory-per-message parsing mechanism.
991 Now through "MIME::Parser" method "output_under()",
992 you can tell the parser that you want it to create
993 a unique directory for each message parsed, to hold the
994 resulting parts.
995 Elimination of $', $` and $&.
997 Wow... I still can't believe I missed this. D'OH!
998 Thanks to Noel Burton-Krahn for all his patches.
999 Parser is more tolerant of weird EOL termination.
1001 Some mailagents are can terminate lines with "\r\r\n".
1002 We're okay with that now when we extract the header.
1003 Thanks to Joao Fonseca for pointing this out.
1004 Parser is tolerant of "From " lines in headers.
1006 Thanks to Joachim Wieland, Anthony Hinsinger, Marius Stan,
1007 and numerous others.
1008 Parser catches syntax errors in headers.
1010 Thanks to Russell P. Sutherland for catching this.
1011 Parser no longer warns when subtype is undefined.
1013 Thanks to Eric-Olivier Le Bigot for his fix.
1014 Better integration with Mail::Internet.
1016 For example, smtpsend() should work fine.
1017 Thanks to Michael Fischer and others for the patch.
1018 Miscellaneous cleanup.
1020 Thanks to Marcus Brinkmann for additional helpful input.
1021 Thanks to Klaus Seidenfaden for good feedback on 5.x Alpha!
1022 Version 4.123 (1999/05/12)
1024 Cleaned up some of the tests for non-Unix OS'es. Will require a
1025 few iterations, no doubt.
1026 Version 4.122 (1999/02/09)
1028 Resolved CORE::open warnings for 5.005.
1029 Thanks to several folks for this bug report.
1030 Version 4.121 (1998/06/03)
1032 Fixed MIME::Words infinite recursion.
1033 Thanks to several folks for this bug report.
1034 Version 4.117 (1998/05/01)
1036 Nicer MIME::Entity::build.
1037 No longer outputs warnings with undefined Filename, and now
1038 accepts Charset as well. Thanks to Jason Tibbits III
1039 for the inspirational patch.
1040 Documentation fixes.
1042 Hopefully we've seen the last of the pod2man warnings...
1043 Better test logging.
1045 Now uses ExtUtils::TBone.
1046 Version 4.116 (1998/02/14)
1048 Bug fix:
1049 MIME::Head and MIME::Entity were not downcasing the
1050 content-type as they claimed. This has now been fixed.
1051 Thanks to Rodrigo de Almeida Siqueira for finding this.
1052 Version 4.114 (1998/02/12)
1054 Gzip64-encoding has been improved, and turned off as a default,
1055 since it depends on having gzip installed.
1056 See MIME::Decoder::Gzip64 if you want to activate it in
1057 your app. You can now set up the gzip/gunzip commands to
1058 use, as well. Thanks to Paul J. Schinder for finding this
1059 bug.
1060 Version 4.113 (1998/01/20)
1062 Bug fix:
1063 MIME::ParserBase was accidentally folding newlines in
1064 header fields. Thanks to Jason L. Tibbitts III for spotting
1065 this.
1066 Version 4.112 (1998/01/17)
1068 MIME::Entity::print_body now recurses when printing multipart
1069 entities, and prints "everything following the header." This
1070 is more likely what people expect to happen. PLEASE read the
1071 "two body problem" section of MIME::Entity's docs.
1072 Version 4.111 (1998/01/14)
1074 Clean build/test on Win95 using 5.004. Whew.
1075 Version 4.110 (1998/01/11)
1077 Added make_multipart() and make_singlepart() in MIME::Entity.
1078 Improved handling/saving of preamble/epilogue.
1080 Version 4.109 (1998/01/10)
1082 Overall
1083 Major version shift to 4.x accompanies numerous structural
1084 changes, and the deletion of some long-deprecated code.
1085 Many apologies to those who are inconvenienced by the
1086 upgrade.
1087 MIME::IO deprecated. You'll see IO::Scalar, IO::ScalarAr‐
1089 ray, and IO::Wrap to make this toolkit work.
1090 MIME::Entity deep code. You can now deep-copy MIME enti‐
1092 ties (except for on-disk data files).
1093 Encoding/decoding
1095 MIME::Latin1 deprecated, and 8-to-7 mapping removed.
1096 Really, MIME::Latin1 was one of my more dumber ideas.
1097 It's still there, but if you want to map 8-bit characters
1098 to Latin1 ASCII approximations when 7bit encoding, you'll
1099 have to request it explicitly. But use quoted-printable
1100 for your 8-bit documents; that's what it's there for!
1101 7bit and 8bit "encoders" no longer encode. As per
1103 RFC-2045, these just do a pass-through of the data, but
1104 they'll warn you if you send bad data through.
1105 MIME::Entity suggests encoding. Now you can ask
1107 MIME::Entity's build() method to "suggest" a legal encod‐
1108 ing based on the body and the content-type. No more
1109 guesswork! See the "mimesend" example.
1110 New module structure for MIME::Decoder classes. It should
1112 be easier for you to see what's happening.
1113 New MIME decoders! Support added for decoding "x-uuen‐
1115 code", and for decoding/encoding "x-gzip64". You'll need
1116 "gzip" to make the latter work.
1117 Quoted-printable back on track... and then some. The
1119 'quoted-printable' decoder now uses the newest MIME::Quoted‐
1120 Print, and amends its output with guideline #8 from
1121 RFC2049 (From/.). Thanks to Denis N. Antonioli for sug‐
1122 gesting this.
1123 Parsing
1125 Preamble and epilogue are now saved. These are saved in
1126 the parsed entities as simple string-arrays, and are out‐
1127 put by print() if there. Thanks to Jason L. Tibbitts for
1128 suggesting this.
1129 The "multipart/digest" semantics are now preserved. Parts
1131 of digest messages have their mime_type() defaulted to
1132 "message/rfc822" instead of "text/plain", as per the RFC.
1133 Thanks to Carsten Heyl for suggesting this.
1134 Output
1136 Well-defined, more-complete print() output. When printing
1137 an entity, the output is now well-defined if the entity
1138 came from a MIME::Parser, even if using parse_nested_messages.
1139 See MIME::Entity for details.
1140 You can prevent recommended filenames from being output.
1142 This possible security hole has been plugged; when build‐
1143 ing MIME entities, you can specify a body path but sup‐
1144 press the filename in the header. Thanks to Jason L.
1145 Tibbitts for suggesting this.
1146 Bug fixes
1148 Win32 installations should work. The binmode() calls
1149 should work fine on Win32 now. Thanks to numerous folks
1150 for their patches.
1151 MIME::Head::add() now no longer downcases its argument.
1153 Thanks to Brandon Browning & Jason L. Tibbitts for finding
1154 this bug.
1155 Version 3.204
1157 Bug in MIME::Head::original_text fixed. Well, it took a
1158 while, but another bug surfaced from my transition from 1.x to
1159 2.x. This method was, quite idiotically, sorting the header
1160 fields. Thanks, as usual, to Andreas Koenig for spotting this
1161 one.
1162 MIME::ParserBase no longer defaults to RFC-1522-decoding headers.
1164 The documentation correctly stated that the default setting
1165 was to not RFC-1522-decode the headers. The code, on the
1166 other hand, was init'ing this parser option in the "on" posi‐
1167 tion. This has been fixed.
1168 MIME::ParserBase::parse_nested_messages reexamined. If you
1170 use this feature, please re-read the documentation. It
1171 explains a little more precisely what the ramifications are.
1172 MIME::Entity tries harder to ensure MIME compliance. It is
1174 now a fatal error to use certain bad combinations of content
1175 type and encoding when "building", or to attempt to "attach"
1176 to anything that is not a multipart document. My apologies if
1177 this inconveniences anyone, but it was just too darn easy
1178 before for folks to create bad MIME, and gosh darn it, good
1179 libraries should at least try to protect you from mistakes.
1180 The "make" now halts if you don't have the right stuff, pro‐
1182 vided your MakeMaker supports PREREQ_PM. See "REQUIREMENTS"
1183 for what you need to install this package. I still provide
1184 old courtesy copies of the MIME:: decoding modules. Thanks to
1185 Hugo van der Sanden for suggesting this.
1186 The "make test" is far less chatty. Okay, okay, STDERR is
1188 evil. Now a "make test" will just give you the important
1189 stuff: do a "make test TEST_VERBOSE=1" if you want the gory
1190 details (advisable if sending me a bug report). Thanks to Andreas
1191 Koenig for suggesting this.
1192 Version 3.203
1194 No, there haven't been any major changes between 2.x and 3.x.
1195 The major-version increase was from a few more tweaks to get
1196 $VERSION to be calculated better and more efficiently (I had
1197 been using RCS version numbers in a way which created problems
1198 for users of CPAN::). After a couple of false starts, all
1199 modules have been upgraded to RCS 3.201 or higher.
1200 You can now parse a MIME message from a scalar, an
1202 array-of-scalars, or any MIME::IO-compliant object (including IO::
1203 objects.) Take a look at parse_data() in MIME::ParserBase.
1204 The parser code has been modified to support the MIME::IO
1205 interface. Thanks to fellow Chicagoan Tim Pierce (and count‐
1206 less others) for asking.
1207 More sensible toolkit configuration. A new config() method in
1209 MIME::ToolUtils makes a lot of toolkit-wide configuration
1210 cleaner. Your old calls will still work, but with deprecation
1211 warnings.
1212 You can now sign messages just like in Mail::Internet. See
1214 MIME::Entity for the interface.
1215 You can now remove signatures from messages just like in
1217 Mail::Internet. See MIME::Entity for the interface.
1218 You can now compute/strip content lengths and other non-stan‐
1220 dard MIME fields. See sync_headers() in MIME::Entity.
1221 Thanks to Tim Pierce for bringing the basic problem to my
1222 attention.
1223 Many warnings are now silent unless $^W is true. That means
1225 unless you run your Perl with "-w", you won't see
1226 deprecation warnings, non-fatal-error messages, etc.
1227 But of course you run with "-w", so this doesn't affect
1228 you. ":-)"
1229 Completed the 7-bit encodings in MIME::Latin1. We hadn't had
1231 complete coverage in the conversion from 8- to 7-bit; now we
1232 do. Thanks to Rolf Nelson for bringing this to my attention.
1233 Fixed broken parse_two() in MIME::ParserBase. BTW, if your
1235 code worked with the "broken" code, it should still work.
1236 Thanks again to Tim Pierce for bringing this to my attention.
1237 Version 2.14
1239 Just a few bug fixes to improve compatibility with Mail-Tools 1.08,
1240 and with the upcoming Perl 5.004 release. Thanks to Jason L. Tib‐
1241 bitts III for reporting the problems so quickly.
1242 Version 2.13
1244 New features
1245 Added RFC-1522-style decoding of encoded header fields.
1246 Header decoding can now be done automatically during pars‐
1247 ing via the new "decode()" method in MIME::Head... just
1248 tell your parser object that you want to "decode_head‐
1249 ers()". Thanks to Kent Boortz for providing the idea, and
1250 the baseline RFC-1522-decoding code!
1251 Building MIME messages is even easier. Now, when you use
1253 MIME::Entity's "build()" or "attach()", you can also sup‐
1254 ply individual mail headers to set (e.g., "-Subject",
1255 "-From", "-To").
1256 Added "Disposition" to MIME::Entity's "build()" method.
1258 Thanks to Kurt Freytag for suggesting this feature.
1259 An "X-Mailer" header is now output by default in all MIME-
1261 Entity-prepared messages, so any bad MIME we generate can
1262 be traced back to this toolkit.
1263 Added "purge()" method to MIME::Entity for deleteing leftover
1265 files. Thanks to Jason L. Tibbitts III for suggesting
1266 this feature.
1267 Added "seek()" and "tell()" methods to built-in MIME::IO
1269 classes. Only guaranteed to work when reading!
1270 Thanks to Jason L. Tibbitts III for suggesting this fea‐
1271 ture.
1272 When parsing a multipart message with apparently no boundaries,
1274 the error message you get has been improved. Thanks
1275 to Andreas Koenig for suggesting this.
1276 Bug fixes
1278 Patched over a Perl 5.002 (and maybe earlier and later) bug
1279 involving FileHandle::new_tmpfile. It seems that the underly‐
1280 ing filehandles were not being closed when the FileHandle
1281 objects went out of scope! There is now an internal routine
1282 that creates true FileHandle objects for anonymous temp files.
1283 Thanks to Dragomir R. Radev and Zyx for reporting the weird
1284 behavior that led to the discovery of this bug.
1285 MIME::Entity's "build()" method now warns you if you give it an
1287 illegal boundary string, and substitutes one of its own.
1288 MIME::Entity's "build()" method now generates safer,
1290 fully-RFC-1521-compliant boundary strings.
1291 Bug in MIME::Decoder's "install()" method was fixed. Thanks to
1293 Rolf Nelson and Nickolay Saukh for finding this.
1294 Changed FileHandle::new_tmpfile to FileHandle->new_tmpfile, so
1296 some Perl installations will be happier. Thanks to Larry W.
1297 Virden for finding this bug.
1298 Gave "=over" an arg of 4 in all PODs. Thanks to Larry W. Vir‐
1300 den for pointing out the problems of bare =over's
1301 Version 2.04
1303 A bug in MIME::Entity's output method was corrected.
1304 MIME::Entity::print now outputs everything to the desired filehan‐
1305 dle explicitly. Thanks to Jake Morrison for pointing out the
1306 incompatibility with Mail::Header.
1307 Version 2.03
1309 Fixed bug in autogenerated filenames resulting from transposed "if"
1310 statement in MIME::Parser, removing spurious printing of header as
1311 well. (Annoyingly, this bug is invisible if debugging is turned
1312 on!) Thanks to Andreas Koenig for bringing this to my attention.
1313 Fixed bug in MIME::Entity::body() where it was using the bodyhandle
1315 completely incorrectly. Thanks to Joel Noble for bringing this to
1316 my attention.
1317 Fixed MIME::Head::VERSION so CPAN:: is happier. Thanks to Larry
1319 Virden for bringing this to my attention.
1320 Fixed undefined-variable warnings when dumping skeleton (happened
1322 when there was no Subject: line) Thanks to Joel Noble for bringing
1323 this to my attention.
1324 Version 2.02
1326 Stupid, stupid bugs in both BASE64 encoding and decoding were
1327 fixed. Thanks to Phil Abercrombie for locating them.
1328 Version 2.01
1330 Modules now inherit from the new Mail:: modules! This means big
1331 changes in behavior.
1332 MIME::Parser can now store message data in-core. There were a lot
1334 of requests for this feature.
1335 MIME::Entity can now compose messages. There were a lot of
1337 requests for this feature.
1338 Added option to parse "message/rfc822" as a pseduo-multipart docu‐
1340 ment. Thanks to Andreas Koenig for suggesting this.
1341 Version 1.13
1343 MIME::Head now no longer requires space after ":", although either
1344 a space or a tab after the ":" will be swallowed if there. Thanks
1345 to Igor Starovoitov for pointing out this shortcoming.
1346 Version 1.12
1348 Fixed bugs in parser where CRLF-terminated lines were blowing out
1349 the handling of preambles/epilogues. Thanks to Russell Sutherland
1350 for reporting this bug.
1351 Fixed idiotic is_multipart() bug. Thanks to Andreas Koenig for
1353 noticing it.
1354 Added untested binmode() calls to parser for DOS, etc. systems.
1356 No idea if this will work...
1357 Reorganized the output_path() methods to allow easy use of inheri‐
1359 tance, as per Achim Bohnet's suggestion.
1360 Changed MIME::Head to report mime_type more accurately.
1362 POSIX module no longer loaded by Parser if perl >= 5.002. Hey,
1364 5.001'ers: let me know if this breaks stuff, okay?
1365 Added unsupported ./examples directory.
1367 Version 1.11
1369 Converted over to using Makefile.PL. Thanks to Andreas Koenig for
1370 the much-needed kick in the pants...
1371 Added t/*.t files for testing. Eeeeeeeeeeeh...it's a start.
1373 Fixed bug in default parsing routine for generating output paths;
1375 it was warning about evil filenames if there simply were no recom‐
1376 mended filenames. D'oh!
1377 Fixed redefined parts() method in Entity.
1379 Fixed bugs in Head where field name wasn't being case folded.
1381 Version 1.10
1383 A typo was causing the epilogue of an inner multipart message to be
1384 swallowed to the end of the OUTER multipart message; this has now
1385 been fixed. Thanks to Igor Starovoitov for reporting this bug.
1386 A bad regexp for parameter names was causing some parameters to be
1388 parsed incorrectly; this has also been fixed. Thanks again to Igor
1389 Starovoitov for reporting this bug.
1390 It is now possible to get full control of the filenaming algorithm
1392 before output files are generated, and the default algorithm is
1393 safer. Thanks to Laurent Amon for pointing out the problems, and
1394 suggesting some solutions.
1395 Fixed illegal "simple" multipart test file. D'OH!
1397 Version 1.9
1399 No changes: 1.8 failed CPAN registration
1400 Version 1.8
1402 Fixed incompatibility with 5.001 and FileHandle::new_tmpfile Added
1403 COPYING file, and improved README.
1404
1406 MIME-tools was created by:
1407 ___ _ _ _ _ ___ _
1409 / _ \⎪ '_⎪ ⎪ ⎪ ⎪/ _ ' / Eryq, (eryq@zeegee.com)
1410 ⎪ __/⎪ ⎪ ⎪ ⎪_⎪ ⎪ ⎪_⎪ ⎪ President, ZeeGee Software Inc.
1411 \___⎪⎪_⎪ \__, ⎪\__, ⎪__ http://www.zeegee.com/
1412 ⎪___/ ⎪___/
1413 Released as MIME-parser (1.0): 28 April 1996. Released as MIME-tools
1415 (2.0): Halloween 1996. Released as MIME-tools (4.0): Christmas 1997.
1416 Released as MIME-tools (5.0): Mother's Day 2000.
1417
1419 This kit would not have been possible but for the direct contributions
1420 of the following:
1421 Gisle Aas The MIME encoding/decoding modules.
1423 Laurent Amon Bug reports and suggestions.
1424 Graham Barr The new MailTools.
1425 Achim Bohnet Numerous good suggestions, including the I/O model.
1426 Kent Boortz Initial code for RFC-1522-decoding of MIME headers.
1427 Andreas Koenig Numerous good ideas, tons of beta testing,
1428 and help with CPAN-friendly packaging.
1429 Igor Starovoitov Bug reports and suggestions.
1430 Jason L Tibbitts III Bug reports, suggestions, patches.
1431 Not to mention the Accidental Beta Test Team, whose bug reports (and
1433 comments) have been invaluable in improving the whole:
1434 Phil Abercrombie
1436 Mike Blazer
1437 Brandon Browning
1438 Kurt Freytag
1439 Steve Kilbane
1440 Jake Morrison
1441 Rolf Nelson
1442 Joel Noble
1443 Michael W. Normandin
1444 Tim Pierce
1445 Andrew Pimlott
1446 Dragomir R. Radev
1447 Nickolay Saukh
1448 Russell Sutherland
1449 Larry Virden
1450 Zyx
1451 Please forgive me if I've accidentally left you out. Better yet, email
1453 me, and I'll put you in.
1454
1456 At the time of this writing ($Date: 2006/03/17 21:03:23 $), the MIME-
1457 tools homepage was http://www.mimedefang.org/static/mime-tools.php.
1458 Check there for updates and support.
1459 Users of this toolkit may wish to read the documentation of
1461 Mail::Header and Mail::Internet.
1462 The MIME format is documented in RFCs 1521-1522, and more recently in
1464 RFCs 2045-2049.
1465 The MIME header format is an outgrowth of the mail header format docu‐
1467 mented in RFC 822.
1468perl v5.8.8 2006-03-17 MIME::Tools(3)