rjbs / email-mime Goto Github PK

Method invent_filename is used by method filename which returns suggested file name.

But invent_filename uses module global variable counter which is appended into returned file name. Therefore method filename is not stable as documented in Email::MIME documentation and depends on order of Email::MIME objects on which were invent_filename resp. filename called.

MIME email is tree structure and every vertex is MIME part on which can be called invent_filename method. Therefore stable implementation of invent_filename method must uniquely encode vertex in the tree. MIME email is rooted tree, so vertex can be encoded by just the path from root.

see t/part-encs.t

Can't locate object method "new" via package "Email::MIME" at /usr/share/perl5/vendor_perl/HTTP/Request/Params.pm line 86.
I am presently using Fedora 18 release.

Hello,

i have an issue here and dont know to handle. I think i need an experts help. Is this the right place? My issue is this:
I use typical Mailserver postfix->procmail->dovecot(mbox)
By procmail i start a filter which uses a perl script to remove attachments. I use this code to remove attachments: http://www.txoof.com/2011/12/stripping-mime-attachments-from-email.html#!/2011/12/stripping-mime-attachments-from-email.html

This works very well, but in some rare cases it creates an invalid mail in this way:

A single mail in a mbox-file starts with a line like this:
From [email protected] Tue Nov 29 14:47:15 2016
This line is added by MTA and after that line follows content of email.

In some rare cases this line is broken (white space after 16:)
From [email protected] Fri Nov 25 16: 18:08 2016

I cant explain that. Code seems to be ok and í cant find any line which looks suspicious. the only hint i have is that email::mime on this machine is quite old, version is 1.910-1

Is this a known issue in older version of email::mime? i hope so, otherwise i would running out of ideas.
Do you have a clue for me?

Thanks,
Hans

If you do:

        Email::MIME->create(
            attributes => {
                'Content-Type' => 'application/octet-string',
                encoding => 'base64',
                disposition => 'attachment',
                filename => 'hah"ha"\'ha\\',
            },
            body => 'This is my “attachment”.',
        ),

… Email::MIME does not correctly escape the double quote.

The documentation for Email::MIME::body_set states:

This method overrides the default body_set() method.

This is confusing. Does one method called body_set override another method also named body_set? That doesn't seem likely.

Can you investigate?

Thank you very much.
Jim Keenan

If you have an email with multiple levels of subparts, and you call body_str_set() or any other modifier on a deep part, the top level Email::MIME's ->as_string (and other things) should notice that it was changed and reflect those changes accordingly.

(See wolfsage/Email-Footer@5d80744 for an example of something working around this problem).

Long filenames are allowed per RFC 2231.

For example:

Content-Disposition: attachment;
    filename*0="Blank App to Rent _ Application to Rent Screening Fee #1 - 4 03.";
    filename*1=pdf
Content-Type: application/pdf;
    name*0="Blank App to Rent _ Application to Rent Screening Fee #1 - 4 03.";
    name*1=pdf
Content-Transfer-Encoding: base64

However, these extended filenames are not properly returned via the Email::MIME module (or, appropriate submodule). These extended filenames can also become more complex, since character encoding, etc. can be specified as part of the filename. See RFC 2231 for more details (https://tools.ietf.org/html/rfc2231).

There is another module which appears to handle this properly:
http://cpansearch.perl.org/src/MURATAYA/MIME-EcoEncode-0.95/lib/MIME/EcoEncode/Param.pm

Example code:

use Email::MIME;

my $email = Email::MIME->create(
    header_str => [ To => ['[email protected]', '[email protected]'] ]
);
print $email->as_string;

Output:

To: ARRAY(0xc6ba68)
Date: Thu, 12 Jan 2023 10:44:38 +0000
MIME-Version: 1.0

The e-mails appear to be sent correctly, so this is only an issue for the as_string method.

$self->SUPER::body_set(shift @bits) if ($bits[0] || '') !~ /.*:.*/;

This regex is causing a huge slowdown when parsing large mime parts.
Changing to this makes it a lot faster:

$self->SUPER::body_set(shift @bits) if ($bits[0] || '') !~ /:/;

Better yet:

$self->SUPER::body_set(shift @bits) if index(($bits[0] || ''), ':') == -1;

Hi,

When I try to install Email::MIME I've got deep recursion :

Searching Email::MIME::Creator on mirror file:///Users/weborama/Downloads/pinto ...
--> Working on Email::MIME::Creator
Fetching file:///Users/weborama/Downloads/pinto/authors/id/R/RJ/RJBS/Email-MIME-1.929.tar.gz ... OK
Unpacking Email-MIME-1.929.tar.gz
x Email-MIME-1.929
x Email-MIME-1.929/README
x Email-MIME-1.929/Changes
x Email-MIME-1.929/LICENSE
x Email-MIME-1.929/dist.ini
x Email-MIME-1.929/META.yml
x Email-MIME-1.929/MANIFEST
x Email-MIME-1.929/t
x Email-MIME-1.929/t/basic.t
x Email-MIME-1.929/t/dispo.t
x Email-MIME-1.929/t/parts.t
x Email-MIME-1.929/META.json
x Email-MIME-1.929/t/unicode.t
x Email-MIME-1.929/Makefile.PL
x Email-MIME-1.929/t/body-ref.t
x Email-MIME-1.929/t/ct_attrs.t
x Email-MIME-1.929/t/encoding.t
x Email-MIME-1.929/t/Mail
x Email-MIME-1.929/t/Mail/mail-1
x Email-MIME-1.929/t/Mail/mail-2
x Email-MIME-1.929/t/multipart.t
x Email-MIME-1.929/t/part-encs.t
x Email-MIME-1.929/t/content_id.t
x Email-MIME-1.929/t/singlepart.t
x Email-MIME-1.929/t/walk-parts.t
x Email-MIME-1.929/t/auto_create.t
x Email-MIME-1.929/t/disposition.t
x Email-MIME-1.929/t/read-nested.t
x Email-MIME-1.929/t/Mail/att-1.gif
x Email-MIME-1.929/t/nested-parts.t
x Email-MIME-1.929/lib/Email
x Email-MIME-1.929/lib/Email/MIME.pm
x Email-MIME-1.929/t/Mail/nested-parts
x Email-MIME-1.929/t/files
x Email-MIME-1.929/t/files/readme.txt.gz
x Email-MIME-1.929/t/00-report-prereqs.t
x Email-MIME-1.929/t/00-report-prereqs.dd
x Email-MIME-1.929/xt/release
x Email-MIME-1.929/xt/release/pod-syntax.t
x Email-MIME-1.929/lib/Email/MIME
x Email-MIME-1.929/lib/Email/MIME/Encode.pm
x Email-MIME-1.929/lib/Email/MIME/Header.pm
x Email-MIME-1.929/lib/Email/MIME/Creator.pm
x Email-MIME-1.929/lib/Email/MIME/Modifier.pm
x Email-MIME-1.929/xt/release/changes_has_content.t
Entering Email-MIME-1.929
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.04)
Running Makefile.PL
Configuring Email-MIME-1.929 ... Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Email::MIME
Writing MYMETA.yml and MYMETA.json
OK
Checking dependencies from MYMETA.json ...
Checking if you have Encode 1.9801 ... Yes (2.60)
Checking if you have warnings 0 ... Yes (1.23)
Checking if you have Email::Simple::Creator 0 ... Yes (2.204)
Checking if you have Email::Simple 2.102 ... Yes (2.204)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.04)
Checking if you have Test::More 0.96 ... Yes (1.001014)
Checking if you have Scalar::Util 0 ... Yes (1.38)
Checking if you have strict 0 ... Yes (1.08)
Checking if you have Email::MIME::ContentType 1.016 ... Yes (1.017)
Checking if you have MIME::Base64 0 ... Yes (3.14)
Checking if you have Email::Address 0 ... Yes (1.907)
Checking if you have utf8 0 ... Yes (1.13_01)
Checking if you have MIME::Types 1.13 ... Yes (2.09)
Checking if you have parent 0 ... Yes (0.228)
Checking if you have Email::MessageID 0 ... Yes (1.405)
Checking if you have Email::Simple::Header 0 ... Yes (2.204)
Checking if you have Carp 0 ... Yes (1.3301)
Checking if you have File::Spec 0 ... Yes (3.48_01)
Checking if you have Symbol 0 ... Yes (1.07)
Checking if you have Email::MIME::Encodings 1.314 ... Yes (1.315)
Building and testing Email-MIME-1.929 ... cp lib/Email/MIME/Header.pm blib/lib/Email/MIME/Header.pm
cp lib/Email/MIME/Encode.pm blib/lib/Email/MIME/Encode.pm
cp lib/Email/MIME/Creator.pm blib/lib/Email/MIME/Creator.pm
cp lib/Email/MIME/Modifier.pm blib/lib/Email/MIME/Modifier.pm
cp lib/Email/MIME.pm blib/lib/Email/MIME.pm
Manifying 5 pod documents
PERL_DL_NONLAZY=1 "/Users/weborama/perl5/perlbrew/perls/perl-5.20.2/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00-report-prereqs.t .. # 
# Versions for all modules listed in MYMETA.json (including optional ones):
# 
# === Configure Requires ===
# 
#     Module              Want Have
#     ------------------- ---- ----
#     ExtUtils::MakeMaker  any 7.04
# 
# === Build Requires ===
# 
#     Module              Want Have
#     ------------------- ---- ----
#     ExtUtils::MakeMaker  any 7.04
# 
# === Test Requires ===
# 
#     Module              Want     Have
#     ------------------- ---- --------
#     ExtUtils::MakeMaker  any     7.04
#     File::Spec           any  3.48_01
#     Symbol               any     1.07
#     Test::More          0.96 1.001014
#     utf8                 any  1.13_01
# 
# === Test Recommends ===
# 
#     Module         Want     Have
#     ---------- -------- --------
#     CPAN::Meta 2.120900 2.150001
# 
# === Runtime Requires ===
# 
#     Module                     Want   Have
#     ------------------------ ------ ------
#     Carp                        any 1.3301
#     Email::Address              any  1.907
#     Email::MIME::ContentType  1.016  1.017
#     Email::MIME::Encodings    1.314  1.315
#     Email::MessageID            any  1.405
#     Email::Simple             2.102  2.204
#     Email::Simple::Creator      any  2.204
#     Email::Simple::Header       any  2.204
#     Encode                   1.9801   2.60
#     MIME::Base64                any   3.14
#     MIME::Types                1.13   2.09
#     Scalar::Util                any   1.38
#     parent                      any  0.228
#     strict                      any   1.08
#     warnings                    any   1.23
# 
t/00-report-prereqs.t .. ok   
t/auto_create.t ........ 1/? Deep recursion on subroutine "Email::Simple::Header::header" at /Users/weborama/.cpanm/work/1427354601.12544/Email-MIME-1.929/blib/lib/Email/MIME/Header.pm line 54.
Deep recursion on subroutine "Email::MIME::Header::header_raw" at /Users/weborama/perl5/perlbrew/perls/perl-5.20.2/lib/site_perl/5.20.2/Email/Simple/Header.pm line 212.

This bug happens when decoding Quoted-Printable headers, and it is complete weirdo:

Single ć as name:

my $parsed = Email::MIME->new(q{From: =?UTF-8?Q?=C4=87?= <[email protected]>}."\r\n\r\n");
say $parsed->header_str('from');

ć <[email protected]>

(perfect, works)

Single é as name:

my $parsed = Email::MIME->new(q{From: =?UTF-8?Q?=C3=A9?= <[email protected]>}."\r\n\r\n");
say $parsed->header_str('from');

� <[email protected]>

(broken, decoding replaced valid UTF-8 character with replacement character fffd)

Combined éć as name:

my $parsed = Email::MIME->new(q{From: =?UTF-8?Q?=C3=A9=C4=87?= <[email protected]>}."\r\n\r\n");
say $parsed->header_str('from');

éć <[email protected]>

(é suddenly works?)

Email::MIME 1.949
Email::Address::XS 1.04

Originally filed as https://rt.cpan.org/Ticket/Display.html?id=84254 by @ansoni-san

He wrote:

One thing I have always wished Email::MIME would provide is the ability to supply file handles as the body. Right now it's impossible to send attachments without reading them in to memory (unless I have missed something).

I remember reading the code but there was no obvious way to do it. If I could just do this I would never have to see Net::SMTP ever again!

It's the one thing I have always missed in Email::MIME. This is currently unimplemented right?

While type, subtype and charset is inherited to the header of the message for a
single-part, 'flowed' is completely discarded.

Where to fix:
/usr/share/perl5/Email/MIME.pm:787 and following

Hello.

% cat test2.pl 
#!/usr/bin/env perl

use Modern::Perl;
use Email::MIME;

my $raw = <<'RAW';
Content-Type: image/jpeg;
 name="=?UTF-8?B?cHVibGljLmpwZw==?="
RAW
my $email = Email::MIME->new($raw);

say $email->content_type;
say $email->filename;
say Dump $email->{ct};

% perl -I Email-MIME-1.946/lib test2.pl 
image/jpeg; name="public.jpg"
public.jpg
--- 
attributes: 
  name: public.jpg
composite: jpeg
discrete: image
subtype: jpeg
type: image

% perl -I Email-MIME-1.949/lib test2.pl
image/jpeg; name="public.jpg"
=?UTF-8?B?cHVibGljLmpwZw==?=
--- 
attributes: 
  name: =?UTF-8?B?cHVibGljLmpwZw==?=
composite: jpeg
discrete: image
subtype: jpeg
type: image

% perl -E 'use Email::MIME; say $Email::Simple::VERSION; say $Email::MIME::ContentType::VERSION'
2.216
1.024

Is this the correct behavior?
Has the specification changed?

I think this has an effect.
94e3034

Thanks,

Using msgconvert, html message bodies are messed up since the text part is unicode and concatenating them will implicitely convert the html body.
Working patch was supplied fixing the issue, don't ask for more information (not subscribed)

Hi.

We encountered a bug where Email::MIME::filename () did not return the correct filename.

I think the cause is that the order in which mime_decode and parse_content_type work is reversed.

Write down the sample code.

This email is an email forwarding received from Gmail.
It is correctly displayed as "わたあめカメラ_20190401_191226.jpg" on Gmail.

#!/usr/local/bin/perl

use strict;
use Email::MIME;
use Email::MIME::ContentType;
use Email::MIME::Encode;
$Email::MIME::ContentType::STRICT_PARAMS = 0;

my $raw_email = <<'EMAIL';
From [email protected]  Mon Apr  1 19:34:36 2019
Content-Type: multipart/mixed;
	boundary="=_3a1019ab7cce322859164c2d9ceac6c9"
Date: Mon, 01 Apr 2019 12:00:00 +0900
From: [email protected]
To: [email protected]
Subject: dummy subject

--=_3a1019ab7cce322859164c2d9ceac6c9
Content-ID: <[email protected]>
Content-Type: image/gif;
 name="de_01_1071.gif"; 

--=_3a1019ab7cce322859164c2d9ceac6c9
Content-Type: image/jpeg;
 name*0="=?utf-8?B?44KP44Gf44GC44KB44Kr44Oh44OpXzIwMTkwNDAxXzE5MTIyNi5q?="
 name*1=" =?utf-8?B?cGc=?=";

--=_3a1019ab7cce322859164c2d9ceac6c9--
EMAIL

{
    my $email = Email::MIME->new($raw_email);
    my @parts = $email->parts;
    warn $parts[0]->filename; # de_01_1071.gif
    warn $parts[1]->filename; # "わたあめカメラ_20190401_191226.j" pg
}

my $raw_ct = 'image/jpeg; name*0="=?utf-8?B?44KP44Gf44GC44KB44Kr44Oh44OpXzIwMTkwNDAxXzE5MTIyNi5q?=" name*1=" =?utf-8?B?cGc=?="';
{
    my $decoded_ct   = Email::MIME::Encode::mime_decode($raw_ct);
    my $ct           = parse_content_type($decoded_ct);
    my $decoded_name = $ct->{attributes}{name};
    warn $decoded_name; # "わたあめカメラ_20190401_191226.j" pg
}
{
    my $ct           = parse_content_type($raw_ct);
    my $encoded_name = $ct->{attributes}{name};
    my $decoded_name = Email::MIME::Encode::mime_decode($encoded_name);
    warn $decoded_name; # わたあめカメラ_20190401_191226.jpg
}

__END__

% ./bug.pl
de_01_1071.gif at ./bug.pl line 34.
Wide character in warn at ./bug.pl line 35.
"わたあめカメラ_20190401_191226.j" pg at ./bug.pl line 35.
Wide character in warn at ./bug.pl line 43.
"わたあめカメラ_20190401_191226.j" pg at ./bug.pl line 43.
Wide character in warn at ./bug.pl line 49.
わたあめカメラ_20190401_191226.jpg at ./bug.pl line 49.

We have the following bug reported to the Debian package of
Email-MIME, c.f. https://bugs.debian.org/944887

The bug report contains a patch.

It doesn't seem to be a bug in the packaging, so you may want to take
a look. Thanks!

------8<-----------8<-----------8<-----------8<-----------8<-----

Email::MIME fails to handle mail with a boundary value of "0",
since Perl treats 0 as false.  This is a common type of bug in
Perl code.

Reading RFC 2046, the BNF for allowed boundary characters
allows 1-70 characters, so a single "0" is acceptable:

     boundary := 0*69<bchars> bcharsnospace
     bchars := bcharsnospace / " "
     bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                      "+" / "_" / "," / "-" / "." /
                      "/" / ":" / "=" / "?"

------8<-----------8<-----------8<-----------8<-----------8<-----

Thanks for considering,
gregor herrmann,
Debian Perl Group

Notice after updating Email::MIME from 1.940 to version 1.945
The email address '<>' quotes are not preserved if no phrase/name is set

one liner to show the issue with 1.945

$>perl526 -MEmail::MIME::Header -MEmail::MIME::Encode -E 'say Email::MIME::Encode::maybe_mime_encode_header("To", "<iwrestled\@abear.once>", "utf-8")'
    iwrestled@abear.once

$>perl526 -MEmail::MIME::Encode -E 'say Email::MIME::Encode::maybe_mime_encode_header("To", "<iwrestled\@abear.once>", "utf-8")'                      
    <iwrestled@abear.once>

After investigation it bisects to the commit ed7c290 which introduces the usage of Email::Address::XS instead of Email::Address.
But Email::Address is not the source of the problem and the XS one is behaving the same way than the non XS one and preserve the brackets.

> perl -e 'use Email::Address; map { print $_->format . qq[\n] } Email::Address->parse( q[<[email protected]>] );'
[email protected]
> perl -e 'use Email::Address::XS; map { print $_->format . qq[\n] } Email::Address::XS->parse( q[<[email protected]>] );'
[email protected]

The problem comes from the shortcut in maybe_mime_encode_header which only occurs if Email::MIME::Header is loaded...

Hi

I'm in the middle of migration form MIME::Lite to Email::MIME, but I encountered performance issues. So I've profiled sample code:

#!/usr/bin/env perl

use utf8;
use strict;
use warnings;

use Email::MIME;

Email::MIME->create(
    'attributes' => {
        'content_type' => 'text/plain',
        'disposition'  => 'attachment',
        'charset'      => 'UTF-8',
        'encoding'     => 'quoted-printable',
    },
    'header_str' => [
        'From' => '[email protected]',
        'To' => '[email protected]',
        'Subject' => 'Zażółć gęślą jaźń',
        ],
    'body_str' => 'Zażółć gęślą jaźń'
)->as_string for 1..10000;

Full result is available at http://bbkr.org/email_mime_prof/ and here are the parts that can be improved:

mime encode is giant performance killer

maybe_mime_encode_header took 1/4 of total time (inclusive).
Looking deeper I found that bottleneck here is caused by two things - reallocating memory by chopping single characters from beginning of the $text (why not use simple split?) and encoding those single characters that causes calls flood to Encode
http://bbkr.org/email_mime_prof/Email-MIME-Encode-pm-27-line.html#104
Possible optimisation: You can estimate how much the Base 64 encoding will bloat output string -MIME::Base64::encoded_base64_length function can tell you that. And chop many chars at once from $text that will greatly reduce amount of calls to Encode.

header is parsed even if given

http://bbkr.org/email_mime_prof/Email-Simple-pm-6-line.html#108
This is pure waste of CPU cycles, when Email::MIME->create calls Email::Simple->new the end of header is known, no need to invoke costly regexp.

folding header

http://bbkr.org/email_mime_prof/Email-Simple-Header-pm-11-line.html#322
It uses costly string reallocation on regexp replace.
Possible optimisation 1: Cheap return $line . $crlf if length $line < $limit. Most headers are NOT folded so this should save great amount of CPU cycles.
Possible optimisation 2: Use cheaper substrings (combined with index for whitespace location) instead of substitution.
Possible optimisation 3: Use formats. Folding can be expressed as

<<<<<<<<<<<
  <<<<<<<<<< ~~   # repeat unless string is exhausted
$string
.

However I don't know how to respect end of words in this solution.

constants as methods

Some methods, such as CRLF http://bbkr.org/email_mime_prof/Email-Simple-Header-pm-11-line.html#286 are called very often. I'm not sure if there is real need for subclassing this method if CRLF value can be also passed to the constructor. Using $self->{'mycrlf'} in Headers package will be much faster.

explosion of regexps

http://bbkr.org/email_mime_prof/Email-Simple-Header-pm-11-line.html#69
I'm not sure what it does, but 18 regexps per simplest message burns CPU.

content type attribute setters dynamically dispatched

http://bbkr.org/email_mime_prof/Email-MIME-pm-5-line.html#527
New method name is composed for every content type attribute and then dynamic invocation is used.
Possible optimisation 1: static hash that ties attribute name with method reference (or closure to allow subclassing) would be much faster

state %dispatch = (
    'name1' => sub { $_[0]->set_name1($_[1])}
);
return $dispatch{$name}->($self, $value);

content type is parsed event if given explicitly for Email::MIME->create method

http://bbkr.org/email_mime_prof/Email-MIME-pm-5-line.html#462
http://bbkr.org/email_mime_prof/Email-MIME-pm-5-line.html#822
That invokes tons of complete useless regexps.

There are few memory related issues - module requires over twice the message size for str/raw internal storage - that are not included in this report.

I used this to send email in HTML format, but failed to encode both Header and Body in utf8.

If I add use utf8 directive, as I have utf8 string in the source code file, there would be an error:

Wide character in subroutine entry at /path/to/perls/perl-5.20.2/lib/site_perl/5.20.2/Email/MIME/Encodings.pm line 55.

If I don't add use utf8 directive, the Header string would be mis-encoded, since substr in Email::MIME::Encode::mime_encode would split utf8 characters. The code is something like this:

use strict;
use warnings;
use Email::MIME;
use feature 'say';
# use utf8;  # if I don't use this, then header is encoded incorrectly
#binmode(STDOUT, ':utf8');


my $body = '你好';

my $email = Email::MIME->create(
  header_str => [
    To      =>'[email protected]',
    From    => '[email protected]',
    Subject => '你好',
  ],
  body => $body,
  attributes => {
      content_type => 'text/html',
      charset => 'UTF-8',
      encoding => 'quoted-printable',
  },
);

print $email->body();

I want to use Email::MIME::Attachment::Stripper to remove attachments of an E-Mail.

This is the error:

Unquoted = not allowed in Content-Type! at /usr/local/share/perl/5.14.2/Email/MIME.pm line 123
Illegal Content-Type parameter =_134993AC-C12E-408F-97FA-5C77A36BC897 at /usr/local/share/perl/5.14.2/Email/MIME.pm line 123
Email::MIME=HASH(0x15cecb0)

The error occurs when I use this email:

From: Matthias Jung <[email protected]>
Content-Type: multipart/mixed;
        boundary="Apple-Mail=_134993AC-C12E-408F-97FA-5C77A36BC897"
X-Smtp-Server: smtp.uni-kl.de:[email protected]
Date: Wed, 26 Nov 2014 13:59:32 +0100
Subject: testbetreff
X-Universally-Unique-Identifier: B7B0431C-62FD-4826-862F-E936D9CFDAC8
Bcc: Matthias Jung <[email protected]>
To: [email protected]
Message-Id: <[email protected]>
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))


--Apple-Mail=_134993AC-C12E-408F-97FA-5C77A36BC897
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
        charset=us-ascii

testtext test test test test
test test test test test test test test test test

--Apple-Mail=_134993AC-C12E-408F-97FA-5C77A36BC897
Content-Disposition: attachment;
        filename=eicar.zip
Content-Type: application/zip;
        name="eicar.zip"
Content-Transfer-Encoding: base64

UEsDBAoAAAAAAGQ7WyUjS4psRgAAAEYAAAAJAAAAZWljYXIuY29tWDVPIVAlQEFQWzRcUFpYNTQo
UF4pN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCoNClBLAQIU
AAoAAAAAAGQ7WyUjS4psRgAAAEYAAAAJAAAAAAAAAAEAIAD/gQAAAABlaWNhci5jb21QSwUGAAAA
AAEAAQA3AAAAbQAAAAAA
--Apple-Mail=_134993AC-C12E-408F-97FA-5C77A36BC897
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
        charset=us-ascii



--Apple-Mail=_134993AC-C12E-408F-97FA-5C77A36BC897--

I used the latest version from CPAN.

Regards
Matthias

The Synopsis in https://metacpan.org/pod/Email::MIME contains an example for creating a MIME part body for sending a PDF:

body => io( "2004-financials.pdf" )->all,

I'd recommend to change that to

body => io( "2004-financials.pdf" )->binary->all,

... because it matters at least on MSWin32. The CRLFs in the PDF get turned into LFs without binary and thus the PDFs are, sometimes only subtly, broken on the recipient side. Took me a while to track down (and now it it seems obvious).

The test below will print (with 1.925) :

+ multipart/alternative; boundary="--42"

Although I'd expect it to print :

+ multipart/alternative; boundary="--42"
     + text/plain

I've quickly read the RFC and it seems that a mixed or multipart would accept "one or more bodyparts", and thus should be still correct with only a single sub-part. I encountered this bug while working on a e-mail generated by Email::MIME itself (starting with a well-known text-and-HTML email by removing one of the alternative sub-part). So Email::MIME can generate a multipart with a single sub-part (which makes my software work) but cannot parse it back (which makes my tests fail).

#!/usr/bin/perl

use strict;
use warnings;
use Email::MIME;

undef $/;
my $m = Email::MIME->new(<DATA>);
print $m->debug_structure;

__DATA__
From: Bob <[email protected]>
To: Alice <[email protected]>
Subject: Does not parse as expected
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--42"

--42
MIME-Version: 1.0
Content-Type: text/plain

Some basic text part, but no alternative.

--42

Email-MIME-1.949's documentation begins by advising the reader to use Email::Stuffer instead.

NAME
Email::MIME - easy MIME message handling

VERSION
version 1.949

SYNOPSIS
Wait! Before you read this, maybe you just need Email::Stuffer, which is a
much easier-to-use tool for building simple email messages that might have
attachments or both plain text and HTML. If that doesn't do it for you, then
by all means keep reading.

  use Email::MIME;
  my $parsed = Email::MIME->new($message);

However, it appears that the release of version 1.949 has broken Email::Stuffer's test suite.
See: rjbs/Email-Stuffer#54.

(And this has also broken Email::Stuff. https://rt.cpan.org/Ticket/Display.html?id=132721)

Thank you very much.
Jim Keenan

Superflours headers added (Date, MIME-Version) to MIME part when created with Email::MIME->create().

Effects

• breaks HTML parsing
• makes those headers visible in plaintext-view

Tested in

• Outlook 2007
• Google Mail

Breaks Products

• Bugzilla (4.4.5) - All sent E-Mails (Bugzilla/BugMail.pm:369-386)

Potential cause

• Version: 1.926
• File: Email/MIME.pm
• Lines: 199-201

  $CREATOR->_add_to_header(\$header, Date => $CREATOR->_date_header)
    unless exists $headers{Date};
  $CREATOR->_add_to_header(\$header, 'MIME-Version' => '1.0',);

Example - Broken MIME

From: ...
To: ...
Subject: ...
Date: Fri, 22 Aug 2014 14:01:01 +0000
...
Content-Type: multipart/alternative; boundary="14087160611.664C9Fcf.28775";
 charset="UTF-8"
MIME-Version: 1.0


--14087160611.664C9Fcf.28775
Date: Fri, 22 Aug 2014 16:01:01 +0200

MIME-Version: 1.0

Content-Type: text/plain

...
--14087160611.664C9Fcf.28775
Date: Fri, 22 Aug 2014 16:01:01 +0200

MIME-Version: 1.0

Content-Type: text/html

Workaround

Comment out Lines 199-201 in Email/MIME.pm:

From: ...
To: ...
Subject: ...
Date: Fri, 22 Aug 2014 14:01:01 +0000
...
Content-Type: multipart/alternative; boundary="14087160611.664C9Fcf.28775";
 charset="UTF-8"
MIME-Version: 1.0


--14087178291.E665BBdEa.28858
Content-Type: text/plain


...
--14087178291.E665BBdEa.28858
Content-Type: text/html

The documentation for Email::MIME states:

    "attributes" is a hash of MIME attributes to assign to the part, and may
    override portions of the header set in the "header" parameter. The hash
    keys correspond directly to methods for modifying a message from
    "Email::MIME::Modifier". The allowed keys are: content_type, charset,
    name, format, boundary, encoding, disposition, and filename. ...

However, the documentation for Email::MIME::Modifier states:

NAME
    Email::MIME::Modifier - obsolete do-nothing library

VERSION
    version 1.949

This needs clarification.

Thank you very much.
Jim Keenan

Hello,

setting the body of a part "destroys" the boundary definition if the boundary string is longer than 64 characters:

Input, before setting body:

Content-Type: multipart/mixed; boundary="----=_=-_OpenGroupware_org_NGMime-271126-1610362255.619911-39------"

Result, after setting body:

Content-Type: multipart/mixed; boundary*0="----=_=-_OpenGroupware_org_NGMime-271126-1610362255.619911-39--"; boundary*1="----"; boundary="----=_=-_OpenGroupware_org_NGMime-271126-1610362255.619911-39-..."

Thanks,

fse

Hi,

We have the following bug reported to the Debian package of
Email-MIME, c.f. https://bugs.debian.org/960062

------8<-----------8<-----------8<-----------8<-----------8<-----

Package: libemail-mime-perl
Version: 1.946-1
Severity: important
Tags: upstream

Messages with too many tiny MIME parts can OOM on split().

Messages with many nested MIME parts can also fail on deep
recursion (Email::MIME->new calls ->subparts, ->subparts calls
->new, ad infinitum).

Smallish messages can generate these, since the a boundary
only needs to be 4 bytes "--a\n" and the header+body of
each part can just be 4 bytes "x:y\n\n", too.

Perl takes 42 bytes to represent a 4 byte string on 64-bit:

	use Devel::Size; say Devel::Size::total_size("--\n\n")

This affects many other MIME parsers, too.

------8<-----------8<-----------8<-----------8<-----------8<-----

Thanks for considering,
Salvatore Bonaccorso,
Debian Perl Group

Now that Pod::Weaver is fixed, please rerelease this to fix the METHODS section. :)

Hey!

I've noticed that Email::MIME defaults the charset attribute to us-ascii if the parts list has only 1 element even though that element's charset is explicitly set to something other than us-ascii, e.g. UTF-8.

Example:

#!/usr/bin/perl
use warnings;
use strict;
use Email::MIME;

my $email = Email::MIME->create(
    header_str => [
        From => qq{"Your name" <your_email\@some-domain.com>},
        To => qq{"The recipients's name" <recipients_email\@some-domain.com>},
        Subject => qq{Lorem ipsum dolor}
    ],
    parts => [
        Email::MIME->create(
            attributes => {
                encoding => 'quoted-printable',
                content_type => 'text/plain',
                charset => 'UTF-8'
            },
            body_str => qq{Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam ultricies condimentum felis, eu auctor ex mattis eu. Ut at diam et tortor imperdiet fringilla. Mauris hendrerit consequat erat, feugiat condimentum dolor pellentesque in. Curabitur eleifend ornare luctus. Vestibulum eget venenatis metus. Sed at nisl vel dui vestibulum semper nec sed turpis. Nunc ultricies volutpat erat a tempus. Praesent ut dui vel erat blandit tempus id nec sem. Nulla sollicitudin non ex at commodo. Aliquam tempor nunc eget consequat commodo. Donec hendrerit posuere velit et feugiat. Integer vel magna a nulla pellentesque consequat. Mauris vestibulum consectetur quam, vitae fermentum ante cursus sit amet. Sed at elit dignissim, euismod velit non, fermentum nisl.}
        )
    ]
);

print $email->as_string;

Here's the output:

From: "Your name" <[email protected]>
To: "The recipients's name" <[email protected]>
Subject: Lorem ipsum dolor
Date: Tue, 17 Mar 2015 11:21:16 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam ultricies cond=
imentum felis, eu auctor ex mattis eu. Ut at diam et tortor imperdiet fring=
illa. Mauris hendrerit consequat erat, feugiat condimentum dolor pellentesq=
ue in. Curabitur eleifend ornare luctus. Vestibulum eget venenatis metus. S=
ed at nisl vel dui vestibulum semper nec sed turpis. Nunc ultricies volutpa=
t erat a tempus. Praesent ut dui vel erat blandit tempus id nec sem. Nulla =
sollicitudin non ex at commodo. Aliquam tempor nunc eget consequat commodo.=
 Donec hendrerit posuere velit et feugiat. Integer vel magna a nulla pellen=
tesque consequat. Mauris vestibulum consectetur quam, vitae fermentum ante =
cursus sit amet. Sed at elit dignissim, euismod velit non, fermentum nisl.=

The problem goes away as soon as the parts list has more than 1 element.

I'm using version 1.929

cpan -D Email::MIME
Reading '/root/.cpan/Metadata'
  Database was generated on Sun, 15 Mar 2015 10:53:29 GMT
Email::MIME
-------------------------------------------------------------------------
        (no description)
        R/RJ/RJBS/Email-MIME-1.929.tar.gz
        /usr/local/share/perl/5.14.2/Email/MIME.pm
        Installed: 1.929
        CPAN:      1.929  up to date
        Ricardo SIGNES (RJBS)
        [email protected]

The create() docs say:

If body_str is given instead of body or parts, it is assumed to be a character string to be used as the body. If you provide a body_str parameter, you must provide charset and encoding attributes.

Ok, but what values should charset and encoding have? The values that correspond to the $body_str I'm giving, or those I want in the email that's sent?

The body_str_set docs say:

This method behaves like body_set, but assumes that the given value is a Unicode string that should be encoded into the message's charset before being set. If the charset can't be determined, an exception is thrown.

which suggests that it tries to 'determine' the charset. By itself? Or relying on a previously set charset attribute?

All I want to do is send a simple email message with a body string that's a perl string of characters. I don't want to have to think about charsets and encodings. Can't Email::MIME have reasonable defaults for this (presumably) common case? Perhaps it does but it's not clear to me from the docs.

I'd love a simple example in the docs for this case.

A multi-part message that has subparts without an explicit content-type (or any other headers) is misparsed. For example:

em.pl:

#!/usr/bin/perl

use strict;
use warnings;

use Email::MIME;

open(my $fh, '<', shift) or die "Failed: $!\n";
local $/;
my $data = <$fh>;
close $fh;

my $em = Email::MIME->new($data);

my @parts = $em->subparts;

print "Part one (with content-type): \n" . $parts[0]->body . "\n";

print "Part two (without content-type): \n" . $parts[1]->body . "\n";

When run against this file:

ex.email

From: Test <[email protected]>
To: Test <[email protected]>
Subject: Test
Content-Type: multipart/alternative; boundary=90e6ba6e8d06f1723604fc1b809a

--90e6ba6e8d06f1723604fc1b809a
Content-Type: text/plain; charset=UTF-8

Paragraph 1

Paragraph 2

--90e6ba6e8d06f1723604fc1b809a

Paragraph 1

Paragraph 2

--90e6ba6e8d06f1723604fc1b809a--

prints out:

./em.pl ex.email
Use of uninitialized value in lc at /usr/local/share/perl/5.14.2/Email/Simple/Header.pm line 125.
Use of uninitialized value in lc at /usr/local/share/perl/5.14.2/Email/Simple/Header.pm line 125.
Part one (with content-type): 
Paragraph 1

Paragraph 2
Use of uninitialized value in lc at /usr/local/share/perl/5.14.2/Email/Simple/Header.pm line 125.
Part two (without content-type): 
Paragraph 2

Note that the warnings all come from the second subpart; if a content-type is set in it as in the first subpart, the warnings go away and it works as expected.

I suspect the first paragraph in the second subpart is being parsed as a header.

t/encode-check.t .. 
ok 1 - require Email::MIME;
    ok 1 - we created an email with badly encoded data
    ok 2 - Our non us-ascii char was replaced with a question mark
    ok 3 - as_string looks nice
    1..3
ok 2 - encode_check 0 during create()
    ok 1 - we created an email with badly encoded data
    ok 2 - Our non us-ascii char was replaced with a question mark
    ok 3 - as_string unchanged from input...
    1..3
ok 3 - encode_check 0 during new()
    ok 1 - encode_check 1 with bad data crashes
    1..1
ok 4 - encode_check 1 during create()
    ok 1 - encode_check default with bad data crashes
    1..1
ok 5 - encode_check default during create()
    ok 1 - encode_check 1 with bad data crashes
    1..1
ok 6 - encode_check 1 during new()
    ok 1 - encode_check default with bad data crashes
    1..1
ok 7 - encode_check default during new()
1..7
1..7
The plan was already output at /usr/share/perl/5.14/Test/Builder.pm line 2423.
All 7 subtests passed 

Test Summary Report
-------------------
t/encode-check.t (Wstat: 0 Tests: 7 Failed: 0)
  Parse errors: More than one plan found in TAP output
Files=1, Tests=7,  0 wallclock secs ( 0.06 usr  0.01 sys +  0.15 cusr  0.01 csys =  0.23 CPU)
Result: FAIL

Reason is that test has both: use Test::More 'no_plan'; and done_testing; which cause that plan is printed two times.

Took me forever to find this since it violated some of my assumptions, like that if any header values handled UTF-8 correctly they all would :-).

UTF-8 in header string values works fine for Subject and To. However, if I pass a header string value for the header "X-Minicon-DB" that Encode::is_utf8() believes is UTF-8 (even if none of the characters are non-ASCII), an attempt to send an email with that header times out (with SMTP transport).

I finally demonstrated this by using Encode::encode() and Encode::decode() to force the two states; ASCII works consistently, UTF-8 hangs consistently.

The following code fragment creates a header array later used in Email::MIME->Create(); when that second line is a decode() call, sending the email created hangs with Sending failed: error at after DATA: 4.4.2 homiemail-a25.g.dreamhost.com Error: timeout exceeded. When it is an encode() call, sending the email succeeds. (This is descended from production code but rather simplified at this point.)

my $xmdb = '53 pr1 350141';
$xmdb = decode('UTF-8', $xmdb);      # encode() sends okay, decode() hangs in SMTP transport later
print "xmdb \"$xmdb\" utf-8 ", is_utf8($xmdb)? 'y':'n', "\n";
my $header_str = [
 'From'	=> "Minicon <empubs\@minicon$mcnum.mnstf.org>",
 'To'	=> '"' . $topguy->{'name'} . '" <' . $destemail . '>',
 'X-Minicon-DB' => $xmdb,
 'Subject' => "Minicon $mcnum Progress Report 1",
 ];

Once I determined what was causing the hang (which probably took me longer than it should have; the fact that some headers with utf-8 values worked lead me to put off testing that as the cause until late, so I wasted time checking lots of other things that weren't the cause), it is of course easy to work around the problem, by using encode(). Still, this probably isn't the intended behavior, and if it is it should at least be documented clearly (or maybe I missed finding it).

It's not clear whether this is an issue, or not, but it certainly caught me by surprise:

my $mixed = Email::MIME->create(
    attributes => {content_type => "multipart/mixed"},
    header_str => [Subject => "Subject"],
);
my $related = Email::MIME->create(
    attributes => {content_type => "multipart/related"},
);
$mixed->parts_add([$related]);
print $mixed->as_string;

Results in:

Subject: Subject
Date: Mon, 25 Aug 2014 10:13:30 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1408976010.DFC040.11480"


--1408976010.DFC040.11480
Subject: Subject
Date: Mon, 25 Aug 2014 10:13:30 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed


--1408976010.DFC040.11480
Date: Mon, 25 Aug 2014 10:13:30 -0400
MIME-Version: 1.0
Content-Type: multipart/related

--1408976010.DFC040.11480--

My expectation is that doing a parts_add() with a single new part would be equivalent to parts_set() with the same part, which results in:

Subject: Subject
Date: Mon, 25 Aug 2014 10:15:15 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="1408976115.Be2FCB00.11602"


--1408976115.Be2FCB00.11602
Date: Mon, 25 Aug 2014 10:15:15 -0400
MIME-Version: 1.0
Content-Type: multipart/related


--1408976115.Be2FCB00.11602--

Anecdotally, these mixed-within-mixed messages appear to render completely blank in Windows Live Mail.

my $m=Email::MIME->create(header_str=>[To=>"foo"],body=>"bar");
print $m->as_string;

with Email::MIME 1.940 prints:

To: foo
Date: Tue, 18 Aug 2020 10:52:39 +0000
MIME-Version: 1.0

bar

but with 1.949 prints:

Argument contains empty address at /data0/www/adcourier.broadbean/.perlbrew/libs/perl-5.18.4@delayed-email/lib/perl5/Email/MIME/Encode.pm line 71.
To: 
Date: Tue, 18 Aug 2020 10:53:25 +0000
MIME-Version: 1.0

bar

Email::MIME::Header::AddressList removes malformed elements; I don't think this is the expected behaviour, but at least it should be clearly documented.

I am the current developer for the FreeToastHost website system, used by over 10,000 Toastmasters clubs worldwide.

The system successfully employs Email::Simple, Email::MIME, and Email::Sender.

Our mail system is essentially an email forwarding and distribution list system. We convert system provided email addresses sent through the email handler code on the server to actual email addresses that users enter via the web interface and are stored in our MySQL database.

Unfortunately, because some email distribution lists are to non-club members, we require the insertion of unsubscribe links at the bottom of the mail bodies to protect the server's email reputation. We are successfully using walk_parts from Email::MIME to accomplish that.

However, here is the catch. Altering the emails like this requires that we delete DKIM headers from the incoming email since they would be invalid. Also, we have to make sure the FROM header consistently reflects our server address. Consequentially, sending the outgoing email without the DKIM headers has gradually led to a drop in our deliverability over time. We have occasional problems with MS-Hotmail/Outlook, for example, and have to instruct our users to white list us which they do not like.

I am looking to create new DKIM headers for the outgoing mail. We have the DNS records set up for this.

I ran across Mail::DKIM::Signer, apparently by another author. At first glance, it looks like it requires a message format (line termination codes) that might be incompatible with Email::MIME.

Do you know if there are any incompatibilities between the two? Do you have any experience using the two modules together? (I will be ask the same question to the author of Mail::DKIM::Signer.)

Hi,

Running into a potential bug around the header handling.

I have an email which has been forwarded, and when the forwarded body is extracted with:

# $mail_in = the forwarded email "as is"
my $mail = Email::MIME->new($mail_in);

my $body; for my $subpart ($part->parts) { $body .= $subpart->body; }

for my $part ($mail->parts) {
if ($part->content_type =~ m!text/plain! || $part->content_type =~ m!text/html! || $part->content_type eq '') {
    ... # not relevant, but for context ...
}
elsif ($part->content_type =~ m!multipart/alternative!) {

    # Now here -> when I try to pull the $body to extract the headers from the forwarded email:
    my $msg = Email::MIME->new($body);
    # ^ it produces the error (see next code block bellow for "Error:")
    # This works on multiple emails, except this one here (see the last code block for "Original Email")
}

When I create a new msg with:

my $msg = Email::MIME->new($data);

Error:

Use of uninitialized value in lc at /usr/local/share/perl/5.14.2/Email/Simple/Header.pm line 126, <STDIN> line 300.
Use of uninitialized value in lc at /usr/local/share/perl/5.14.2/Email/Simple/Header.pm line 126, <STDIN> line 300.

The same happens then for each header. Although extracting the $msg->body_raw works fine.

Original Email (the FW part, minus headers from FW) - the "$body" that becomes $msg:

https://pastebin.com/6JG6MnkV

1.926 on Ubuntu 14.10, brewed perl 5.18.2:

Subroutine header redefined at /Users/daveh/perl5/perlbrew/perls/perl-5.18.2/lib/site_perl/5.18.2/EMail/MIME/Header.pm line 32.
Subroutine header_raw redefined at /Users/daveh/perl5/perlbrew/perls/perl-5.18.2/lib/site_perl/5.18.2/EMail/MIME/Header.pm line 44.
Subroutine header_str_set redefined at /Users/daveh/perl5/perlbrew/perls/perl-5.18.2/lib/site_perl/5.18.2/EMail/MIME/Header.pm line 50.
Subroutine _header_decode_str redefined at /Users/daveh/perl5/perlbrew/perls/perl-5.18.2/lib/site_perl/5.18.2/EMail/MIME/Header.pm line 60.

Hey there - my projects' unit tests started failing due to the latest Email::MIME changes.

You can reproduce it with this snippet:

use Email::MIME;
use Email::MIME::CreateHTML;

Email::MIME->create_html(
    header => [
        To => '[email protected]',
        From => '[email protected]',
    ],
    body => 'Hello world',
    text_body => 'Hey world',
    text_body_attributes => {
        content_type => 'text/plain; charset=utf-8',
    }
);

This gives you this message:
Invalid Content-Type 'subtype' parameter

Prior to these recent changes, this code worked fine.

The problem seems to be related to this change: e80d8a4

I'm not sure what to propose as a fix.

Hey,

it's nice that you've implemented header_str_pairs. Please also implement header_str which would work like header (from Email::Simple) does but returns the strings decoded, if possible. This would make querying existing headers a lot easier and Email::MIME's interface a lot more complete and logical.

Thans for considering it.

Not sure if the example under walk_parts is at issue or if there's something funky about Fastmail, but using the example code doesn't return a true value for subparts. It will turn around and correctly say can't get body as a string for multipart/alternative if you ask it for the body_str of the supposedly-not-alternative email, so it's picking up the content type just fine.

There's probably something obvious I'm missing (it's been years since I played around with email) but I'm stumped. (There's also really nothing in the docs about how to deal with multipart/alternative outside of that example, which just returns.)