1MIME::Tools(3)        User Contributed Perl Documentation       MIME::Tools(3)
2
3
4

NAME

6       MIME-tools - modules for parsing (and creating!) MIME entities
7

SYNOPSIS

9       Here's some pretty basic code for parsing a MIME message, and
10       outputting its decoded components to a given directory:
11
12           use MIME::Parser;
13
14           ### Create parser, and set some parsing options:
15           my $parser = new MIME::Parser;
16           $parser->output_under("$ENV{HOME}/mimemail");
17
18           ### Parse input:
19           $entity = $parser->parse(\*STDIN) or die "parse failed\n";
20
21           ### Take a look at the top-level entity (and any parts it has):
22           $entity->dump_skeleton;
23
24       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
27           use MIME::Entity;
28
29           ### 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
35           ### Part #1: a simple text document:
36           $top->attach(Path=>"./testin/short.txt");
37
38           ### Part #2: a GIF file:
39           $top->attach(Path        => "./docs/mime-sm.gif",
40                        Type        => "image/gif",
41                        Encoding    => "base64");
42
43           ### Part #3: some literal text:
44           $top->attach(Data=>$message);
45
46           ### Send it:
47           open MAIL, "| /usr/lib/sendmail -t -oi -oem" or die "open: $!";
48           $top->print(\*MAIL);
49           close MAIL;
50
51       For more examples, look at the scripts in the examples directory of the
52       MIME-tools distribution.
53

DESCRIPTION

55       MIME-tools is a collection of Perl5 MIME:: modules for parsing,
56       decoding, and generating single- or multipart (even nested multipart)
57       MIME messages.  (Yes, kids, that means you can send messages with
58       attached GIF files).
59

REQUIREMENTS

61       You will need the following installed on your system:
62
63               File::Path
64               File::Spec
65               IPC::Open2              (optional)
66               MIME::Base64
67               MIME::QuotedPrint
68               Net::SMTP
69               Mail::Internet, ...     from the MailTools distribution.
70
71       See the Makefile.PL in your distribution for the most-comprehensive
72       list of prerequisite modules and their version numbers.
73

A QUICK TOUR

75   Overview of the classes
76       Here are the classes you'll generally be dealing with directly:
77
78           (START HERE)            results() .-----------------.
79                 \                 .-------->| MIME::          |
80                  .-----------.   /          | Parser::Results |
81                  | MIME::    |--'           `-----------------'
82                  | Parser    |--.           .-----------------.
83                  `-----------'   \ filer()  | MIME::          |
84                     | parse()     `-------->| Parser::Filer   |
85                     | gives you             `-----------------'
86                     | a...                                  | output_path()
87                     |                                       | determines
88                     |                                       | path() of...
89                     |    head()       .--------.            |
90                     |    returns...   | MIME:: | get()      |
91                     V       .-------->| Head   | etc...     |
92                  .--------./          `--------'            |
93            .---> | MIME:: |                                 |
94            `-----| Entity |           .--------.            |
95          parts() `--------'\          | MIME:: |           /
96          returns            `-------->| Body   |<---------'
97          sub-entities    bodyhandle() `--------'
98          (if any)        returns...       | open()
99                                           | returns...
100                                           |
101                                           V
102                                       .--------. read()
103                                       | IO::   | getline()
104                                       | Handle | print()
105                                       `--------' etc...
106
107       To illustrate, parsing works this way:
108
109       ·   The "parser" parses the MIME stream.  A parser is an instance of
110           "MIME::Parser".  You hand it an input stream (like a filehandle) to
111           parse a message from: if the parse is successful, the result is an
112           "entity".
113
114       ·   A parsed message is represented by an "entity".  An entity is an
115           instance of "MIME::Entity" (a subclass of "Mail::Internet").  If
116           the message had "parts" (e.g., attachments), then those parts are
117           "entities" as well, contained inside the top-level entity.  Each
118           entity has a "head" and a "body".
119
120       ·   The entity's "head" contains information about the message.  A
121           "head" is an instance of "MIME::Head" (a subclass of
122           "Mail::Header").  It contains information from the message header:
123           content type, sender, subject line, etc.
124
125       ·   The entity's "body" knows where the message data is.  You can ask
126           to "open" this data source for reading or writing, and you will get
127           back an "I/O handle".
128
129       ·   You can open() a "body" and get an "I/O handle" to read/write
130           message data.  This handle is an object that is basically like an
131           IO::Handle...  it can be any class, so long as it supports a small,
132           standard set of methods for reading from or writing to the
133           underlying data source.
134
135       A typical multipart message containing two parts -- a textual greeting
136       and an "attached" GIF file -- would be a tree of MIME::Entity objects,
137       each of which would have its own MIME::Head.  Like this:
138
139           .--------.
140           | MIME:: | Content-type: multipart/mixed
141           | Entity | Subject: Happy Samhaine!
142           `--------'
143                |
144                `----.
145               parts |
146                     |   .--------.
147                     |---| MIME:: | Content-type: text/plain; charset=us-ascii
148                     |   | Entity | Content-transfer-encoding: 7bit
149                     |   `--------'
150                     |   .--------.
151                     |---| MIME:: | Content-type: image/gif
152                         | Entity | Content-transfer-encoding: base64
153                         `--------' Content-disposition: inline;
154                                      filename="hs.gif"
155
156   Parsing messages
157       You usually start by creating an instance of MIME::Parser and setting
158       up certain parsing parameters: what directory to save extracted files
159       to, how to name the files, etc.
160
161       You then give that instance a readable filehandle on which waits a MIME
162       message.  If all goes well, you will get back a MIME::Entity object (a
163       subclass of Mail::Internet), which consists of...
164
165       ·   A MIME::Head (a subclass of Mail::Header) which holds the MIME
166           header data.
167
168       ·   A MIME::Body, which is a object that knows where the body data is.
169           You ask this object to "open" itself for reading, and it will hand
170           you back an "I/O handle" for reading the data: this could be of any
171           class, so long as it conforms to a subset of the IO::Handle
172           interface.
173
174       If the original message was a multipart document, the MIME::Entity
175       object will have a non-empty list of "parts", each of which is in turn
176       a MIME::Entity (which might also be a multipart entity, etc, etc...).
177
178       Internally, the parser (in MIME::Parser) asks for instances of
179       MIME::Decoder whenever it needs to decode an encoded file.
180       MIME::Decoder has a mapping from supported encodings (e.g., 'base64')
181       to classes whose instances can decode them.  You can add to this
182       mapping to try out new/experiment encodings.  You can also use
183       MIME::Decoder by itself.
184
185   Composing messages
186       All message composition is done via the MIME::Entity class.  For
187       single-part messages, you can use the MIME::Entity/build constructor to
188       create MIME entities very easily.
189
190       For multipart messages, you can start by creating a top-level
191       "multipart" entity with MIME::Entity::build(), and then use the similar
192       MIME::Entity::attach() method to attach parts to that message.  Please
193       note: what most people think of as "a text message with an attached GIF
194       file" is really a multipart message with 2 parts: the first being the
195       text message, and the second being the GIF file.
196
197       When building MIME a entity, you'll have to provide two very important
198       pieces of information: the content type and the content transfer
199       encoding.  The type is usually easy, as it is directly determined by
200       the file format; e.g., an HTML file is "text/html".  The encoding,
201       however, is trickier... for example, some HTML files are
202       "7bit"-compliant, but others might have very long lines and would need
203       to be sent "quoted-printable" for reliability.
204
205       See the section on encoding/decoding for more details, as well as "A
206       MIME PRIMER" below.
207
208   Sending email
209       Since MIME::Entity inherits directly from Mail::Internet, you can use
210       the normal Mail::Internet mechanisms to send email.  For example,
211
212           $entity->smtpsend;
213
214   Encoding/decoding support
215       The MIME::Decoder class can be used to encode as well; this is done
216       when printing MIME entities.  All the standard encodings are supported
217       (see "A MIME PRIMER" below for details):
218
219           Encoding:        | Normally used when message contents are:
220           -------------------------------------------------------------------
221           7bit             | 7-bit data with under 1000 chars/line, or multipart.
222           8bit             | 8-bit data with under 1000 chars/line.
223           binary           | 8-bit data with some long lines (or no line breaks).
224           quoted-printable | Text files with some 8-bit chars (e.g., Latin-1 text).
225           base64           | Binary files.
226
227       Which encoding you choose for a given document depends largely on (1)
228       what you know about the document's contents (text vs binary), and (2)
229       whether you need the resulting message to have a reliable encoding for
230       7-bit Internet email transport.
231
232       In general, only "quoted-printable" and "base64" guarantee reliable
233       transport of all data; the other three "no-encoding" encodings simply
234       pass the data through, and are only reliable if that data is 7bit ASCII
235       with under 1000 characters per line, and has no conflicts with the
236       multipart boundaries.
237
238       I've considered making it so that the content-type and encoding can be
239       automatically inferred from the file's path, but that seems to be
240       asking for trouble... or at least, for Mail::Cap...
241
242   Message-logging
243       MIME-tools is a large and complex toolkit which tries to deal with a
244       wide variety of external input.  It's sometimes helpful to see what's
245       really going on behind the scenes.  There are several kinds of messages
246       logged by the toolkit itself:
247
248       Debug messages
249           These are printed directly to the STDERR, with a prefix of
250           "MIME-tools: debug".
251
252           Debug message are only logged if you have turned "debugging" on in
253           the MIME::Tools configuration.
254
255       Warning messages
256           These are logged by the standard Perl warn() mechanism to indicate
257           an unusual situation.  They all have a prefix of "MIME-tools:
258           warning".
259
260           Warning messages are only logged if $^W is set true and MIME::Tools
261           is not configured to be "quiet".
262
263       Error messages
264           These are logged by the standard Perl warn() mechanism to indicate
265           that something actually failed.  They all have a prefix of
266           "MIME-tools: error".
267
268           Error messages are only logged if $^W is set true and MIME::Tools
269           is not configured to be "quiet".
270
271       Usage messages
272           Unlike "typical" warnings above, which warn about problems
273           processing data, usage-warnings are for alerting developers of
274           deprecated methods and suspicious invocations.
275
276           Usage messages are currently only logged if $^W is set true and
277           MIME::Tools is not configured to be "quiet".
278
279       When a MIME::Parser (or one of its internal helper classes) wants to
280       report a message, it generally does so by recording the message to the
281       MIME::Parser::Results object immediately before invoking the
282       appropriate function above.  That means each parsing run has its own
283       trace-log which can be examined for problems.
284
285   Configuring the toolkit
286       If you want to tweak the way this toolkit works (for example, to turn
287       on debugging), use the routines in the MIME::Tools module.
288
289       debugging
290           Turn debugging on or off.  Default is false (off).
291
292                MIME::Tools->debugging(1);
293
294       quiet
295           Turn the reporting of warning/error messages on or off.  Default is
296           true, meaning that these message are silenced.
297
298                MIME::Tools->quiet(1);
299
300       version
301           Return the toolkit version.
302
303                print MIME::Tools->version, "\n";
304

THINGS YOU SHOULD DO

306   Take a look at the examples
307       The MIME-Tools distribution comes with an "examples" directory.  The
308       scripts in there are basically just tossed-together, but they'll give
309       you some ideas of how to use the parser.
310
311   Run with warnings enabled
312       Always run your Perl script with "-w".  If you see a warning about a
313       deprecated method, change your code ASAP.  This will ease upgrades
314       tremendously.
315
316   Avoid non-standard encodings
317       Don't try to MIME-encode using the non-standard MIME encodings.  It's
318       just not a good practice if you want people to be able to read your
319       messages.
320
321   Plan for thrown exceptions
322       For example, if your mail-handling code absolutely must not die, then
323       perform mail parsing like this:
324
325           $entity = eval { $parser->parse(\*INPUT) };
326
327       Parsing is a complex process, and some components may throw exceptions
328       if seriously-bad things happen.  Since "seriously-bad" is in the eye of
329       the beholder, you're better off catching possible exceptions instead of
330       asking me to propagate "undef" up the stack.  Use of exceptions in
331       reusable modules is one of those religious issues we're never all going
332       to agree upon; thankfully, that's what "eval{}" is good for.
333
334   Check the parser results for warnings/errors
335       As of 5.3xx, the parser tries extremely hard to give you a
336       MIME::Entity.  If there were any problems, it logs warnings/errors to
337       the underlying "results" object (see MIME::Parser::Results).  Look at
338       that object after each parse.  Print out the warnings and errors,
339       especially if messages don't parse the way you thought they would.
340
341   Don't plan on printing exactly what you parsed!
342       Parsing is a (slightly) lossy operation.  Because of things like
343       ambiguities in base64-encoding, the following is not going to spit out
344       its input unchanged in all cases:
345
346           $entity = $parser->parse(\*STDIN);
347           $entity->print(\*STDOUT);
348
349       If you're using MIME::Tools to process email, remember to save the data
350       you parse if you want to send it on unchanged.  This is vital for
351       things like PGP-signed email.
352
353   Understand how international characters are represented
354       The MIME standard allows for text strings in headers to contain
355       characters from any character set, by using special sequences which
356       look like this:
357
358           =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?=
359
360       To be consistent with the existing Mail::Field classes, MIME::Tools
361       does not automatically unencode these strings, since doing so would
362       lose the character-set information and interfere with the parsing of
363       fields (see "decode_headers" in MIME::Parser for a full explanation).
364       That means you should be prepared to deal with these encoded strings.
365
366       The most common question then is, how do I decode these encoded
367       strings?  The answer depends on what you want to decode them to: ASCII,
368       Latin1, UTF-8, etc.  Be aware that your "target" representation may not
369       support all possible character sets you might encounter; for example,
370       Latin1 (ISO-8859-1) has no way of representing Big5 (Chinese)
371       characters.  A common practice is to represent "untranslateable"
372       characters as "?"s, or to ignore them completely.
373
374       To unencode the strings into some of the more-popular Western byte
375       representations (e.g., Latin1, Latin2, etc.), you can use the decoders
376       in MIME::WordDecoder (see MIME::WordDecoder).  The simplest way is by
377       using "unmime()", a function wrapped around your "default" decoder, as
378       follows:
379
380           use MIME::WordDecoder;
381           ...
382           $subject = unmime $entity->head->get('subject');
383
384       One place this is done automatically is in extracting the recommended
385       filename for a part while parsing.  That's why you should start by
386       setting up the best "default" decoder if the default target of Latin1
387       isn't to your liking.
388

THINGS I DO THAT YOU SHOULD KNOW ABOUT

390   Fuzzing of CRLF and newline on input
391       RFC 2045 dictates that MIME streams have lines terminated by CRLF
392       ("\r\n").  However, it is extremely likely that folks will want to
393       parse MIME streams where each line ends in the local newline character
394       "\n" instead.
395
396       An attempt has been made to allow the parser to handle both CRLF and
397       newline-terminated input.
398
399   Fuzzing of CRLF and newline when decoding
400       The "7bit" and "8bit" decoders will decode both a "\n" and a "\r\n"
401       end-of-line sequence into a "\n".
402
403       The "binary" decoder (default if no encoding specified) still outputs
404       stuff verbatim... so a MIME message with CRLFs and no explicit encoding
405       will be output as a text file that, on many systems, will have an
406       annoying ^M at the end of each line... but this is as it should be.
407
408   Fuzzing of CRLF and newline when encoding/composing
409       TODO FIXME All encoders currently output the end-of-line sequence as a
410       "\n", with the assumption that the local mail agent will perform the
411       conversion from newline to CRLF when sending the mail.  However, there
412       probably should be an option to output CRLF as per RFC 2045
413
414   Inability to handle multipart boundaries with embedded newlines
415       Let's get something straight: this is an evil, EVIL practice.  If your
416       mailer creates multipart boundary strings that contain newlines, give
417       it two weeks notice and find another one.  If your mail robot receives
418       MIME mail like this, regard it as syntactically incorrect, which it is.
419
420   Ignoring non-header headers
421       People like to hand the parser raw messages straight from POP3 or from
422       a mailbox.  There is often predictable non-header information in front
423       of the real headers; e.g., the initial "From" line in the following
424       message:
425
426           From - Wed Mar 22 02:13:18 2000
427           Return-Path: <eryq@zeegee.com>
428           Subject: Hello
429
430       The parser simply ignores such stuff quietly.  Perhaps it shouldn't,
431       but most people seem to want that behavior.
432
433   Fuzzing of empty multipart preambles
434       Please note that there is currently an ambiguity in the way preambles
435       are parsed in.  The following message fragments both are regarded as
436       having an empty preamble (where "\n" indicates a newline character):
437
438            Content-type: multipart/mixed; boundary="xyz"\n
439            Subject: This message (#1) has an empty preamble\n
440            \n
441            --xyz\n
442            ...
443
444            Content-type: multipart/mixed; boundary="xyz"\n
445            Subject: This message (#2) also has an empty preamble\n
446            \n
447            \n
448            --xyz\n
449            ...
450
451       In both cases, the first completely-empty line (after the "Subject")
452       marks the end of the header.
453
454       But we should clearly ignore the second empty line in message #2, since
455       it fills the role of "the newline which is only there to make sure that
456       the boundary is at the beginning of a line".  Such newlines are never
457       part of the content preceding the boundary; thus, there is no preamble
458       "content" in message #2.
459
460       However, it seems clear that message #1 also has no preamble "content",
461       and is in fact merely a compact representation of an empty preamble.
462
463   Use of a temp file during parsing
464       Why not do everything in core?  Although the amount of core available
465       on even a modest home system continues to grow, the size of attachments
466       continues to grow with it.  I wanted to make sure that even users with
467       small systems could deal with decoding multi-megabyte sounds and movie
468       files.  That means not being core-bound.
469
470       As of the released 5.3xx, MIME::Parser gets by with only one temp file
471       open per parser.  This temp file provides a sort of infinite scratch
472       space for dealing with the current message part.  It's fast and
473       lightweight, but you should know about it anyway.
474
475   Why do I assume that MIME objects are email objects?
476       Achim Bohnet once pointed out that MIME headers do nothing more than
477       store a collection of attributes, and thus could be represented as
478       objects which don't inherit from Mail::Header.
479
480       I agree in principle, but RFC 2045 says otherwise.  RFC 2045 [MIME]
481       headers are a syntactic subset of RFC-822 [email] headers.  Perhaps a
482       better name for these modules would have been RFC1521:: instead of
483       MIME::, but we're a little beyond that stage now.
484
485       When I originally wrote these modules for the CPAN, I agonized for a
486       long time about whether or not they really should subclass from
487       Mail::Internet (then at version 1.17).  Thanks to Graham Barr, who
488       graciously evolved MailTools 1.06 to be more MIME-friendly, unification
489       was achieved at MIME-tools release 2.0.  The benefits in reuse alone
490       have been substantial.
491

A MIME PRIMER

493       So you need to parse (or create) MIME, but you're not quite up on the
494       specifics?  No problem...
495
496   Glossary
497       Here are some definitions adapted from RFC 1521 (predecessor of the
498       current RFC 204[56789] defining MIME) explaining the terminology we
499       use; each is accompanied by the equivalent in MIME:: module terms...
500
501       attachment
502           An "attachment" is common slang for any part of a multipart message
503           -- except, perhaps, for the first part, which normally carries a
504           user message describing the attachments that follow (e.g.: "Hey
505           dude, here's that GIF file I promised you.").
506
507           In our system, an attachment is just a MIME::Entity under the top-
508           level entity, probably one of its parts.
509
510       body
511           The "body" of an entity is that portion of the entity which follows
512           the header and which contains the real message content.  For
513           example, if your MIME message has a GIF file attachment, then the
514           body of that attachment is the base64-encoded GIF file itself.
515
516           A body is represented by an instance of MIME::Body.  You get the
517           body of an entity by sending it a bodyhandle() message.
518
519       body part
520           One of the parts of the body of a multipart /entity.  A body part
521           has a /header and a /body, so it makes sense to speak about the
522           body of a body part.
523
524           Since a body part is just a kind of entity, it's represented by an
525           instance of MIME::Entity.
526
527       entity
528           An "entity" means either a /message or a /body part.  All entities
529           have a /header and a /body.
530
531           An entity is represented by an instance of MIME::Entity.  There are
532           instance methods for recovering the header (a MIME::Head) and the
533           body (a MIME::Body).
534
535       header
536           This is the top portion of the MIME message, which contains the
537           "Content-type", "Content-transfer-encoding", etc.  Every MIME
538           entity has a header, represented by an instance of MIME::Head.  You
539           get the header of an entity by sending it a head() message.
540
541       message
542           A "message" generally means the complete (or "top-level") message
543           being transferred on a network.
544
545           There currently is no explicit package for "messages"; under
546           MIME::, messages are streams of data which may be read in from
547           files or filehandles.  You can think of the MIME::Entity returned
548           by the MIME::Parser as representing the full message.
549
550   Content types
551       This indicates what kind of data is in the MIME message, usually as
552       majortype/minortype.  The standard major types are shown below.  A
553       more-comprehensive listing may be found in RFC-2046.
554
555       application
556           Data which does not fit in any of the other categories,
557           particularly data to be processed by some type of application
558           program.  "application/octet-stream", "application/gzip",
559           "application/postscript"...
560
561       audio
562           Audio data.  "audio/basic"...
563
564       image
565           Graphics data.  "image/gif", "image/jpeg"...
566
567       message
568           A message, usually another mail or MIME message.
569           "message/rfc822"...
570
571       multipart
572           A message containing other messages.  "multipart/mixed",
573           "multipart/alternative"...
574
575       text
576           Textual data, meant for humans to read.  "text/plain",
577           "text/html"...
578
579       video
580           Video or video+audio data.  "video/mpeg"...
581
582   Content transfer encodings
583       This is how the message body is packaged up for safe transit.  There
584       are the 5 major MIME encodings.  A more-comprehensive listing may be
585       found in RFC-2045.
586
587       7bit
588           No encoding is done at all.  This label simply asserts that no
589           8-bit characters are present, and that lines do not exceed 1000
590           characters in length (including the CRLF).
591
592       8bit
593           No encoding is done at all.  This label simply asserts that the
594           message might contain 8-bit characters, and that lines do not
595           exceed 1000 characters in length (including the CRLF).
596
597       binary
598           No encoding is done at all.  This label simply asserts that the
599           message might contain 8-bit characters, and that lines may exceed
600           1000 characters in length.  Such messages are the least likely to
601           get through mail gateways.
602
603       base64
604           A standard encoding, which maps arbitrary binary data to the 7bit
605           domain.  Like "uuencode", but very well-defined.  This is how you
606           should send essentially binary information (tar files, GIFs, JPEGs,
607           etc.).
608
609       quoted-printable
610           A standard encoding, which maps arbitrary line-oriented data to the
611           7bit domain.  Useful for encoding messages which are textual in
612           nature, yet which contain non-ASCII characters (e.g., Latin-1,
613           Latin-2, or any other 8-bit alphabet).
614

SEE ALSO

616       MIME::Parser, MIME::Head, MIME::Body, MIME::Entity, MIME::Decoder,
617       Mail::Header, Mail::Internet
618
619       At the time of this writing, the MIME-tools homepage was
620       http://www.mimedefang.org/static/mime-tools.php.  Check there for
621       updates and support.
622
623       The MIME format is documented in RFCs 1521-1522, and more recently in
624       RFCs 2045-2049.
625
626       The MIME header format is an outgrowth of the mail header format
627       documented in RFC 822.
628

SUPPORT

630       Please file support requests via rt.cpan.org.
631

CHANGE LOG

633       Released as MIME-parser (1.0): 28 April 1996.  Released as MIME-tools
634       (2.0): Halloween 1996.  Released as MIME-tools (4.0): Christmas 1997.
635       Released as MIME-tools (5.0): Mother's Day 2000.
636
637       See ChangeLog file for full details.
638

AUTHOR

640       Eryq (eryq@zeegee.com), ZeeGee Software Inc (http://www.zeegee.com).
641       Dianne Skoll (dfs@roaringpenguin.com) http://www.roaringpenguin.com.
642
643       Copyright (c) 1998, 1999 by ZeeGee Software Inc (www.zeegee.com).
644       Copyright (c) 2004 by Roaring Penguin Software Inc
645       (www.roaringpenguin.com)
646
647       This program is free software; you can redistribute it and/or modify it
648       under the same terms as Perl itself.
649
650       See the COPYING file in the distribution for details.
651

ACKNOWLEDGMENTS

653       This kit would not have been possible but for the direct contributions
654       of the following:
655
656           Gisle Aas             The MIME encoding/decoding modules.
657           Laurent Amon          Bug reports and suggestions.
658           Graham Barr           The new MailTools.
659           Achim Bohnet          Numerous good suggestions, including the I/O model.
660           Kent Boortz           Initial code for RFC-1522-decoding of MIME headers.
661           Andreas Koenig        Numerous good ideas, tons of beta testing,
662                                   and help with CPAN-friendly packaging.
663           Igor Starovoitov      Bug reports and suggestions.
664           Jason L Tibbitts III  Bug reports, suggestions, patches.
665
666       Not to mention the Accidental Beta Test Team, whose bug reports (and
667       comments) have been invaluable in improving the whole:
668
669           Phil Abercrombie
670           Mike Blazer
671           Brandon Browning
672           Kurt Freytag
673           Steve Kilbane
674           Jake Morrison
675           Rolf Nelson
676           Joel Noble
677           Michael W. Normandin
678           Tim Pierce
679           Andrew Pimlott
680           Dragomir R. Radev
681           Nickolay Saukh
682           Russell Sutherland
683           Larry Virden
684           Zyx
685
686       Please forgive me if I've accidentally left you out.  Better yet, email
687       me, and I'll put you in.
688

LICENSE

690       This program is free software; you can redistribute it and/or modify it
691       under the same terms as Perl itself.
692
693       See the COPYING file for more details.
694
695
696
697perl v5.32.0                      2020-07-28                    MIME::Tools(3)
Impressum