Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-part messages without content-type in subparts are misparsed #14

Open
wolfsage opened this issue Jun 18, 2014 · 4 comments
Open

Comments

@wolfsage
Copy link
Contributor

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.

@eengstrom
Copy link

eengstrom commented Apr 14, 2016

I can confirm this with a fresh CPAN install of Email::MIME (v1.937) and a simpler test case:

#!/usr/bin/env perl
use Email::MIME;

$/ = undef;
my $text = <DATA>;
#print $text;
my $mail = Email::MIME->new($text);

__DATA__
From: [email protected]
To: [email protected]
Subject: failure notice
Content-Type: multipart/mixed; boundary="1446656133441981"

--1446656133441981

content elided

--1446656133441981--

Note that there is only one subpart and it has no content-type. I note that the original report is relatively old (2014). Anyone still interested besides me?

@rjbs
Copy link
Owner

rjbs commented Apr 29, 2016

I am still interested, but I have not been bitten and so haven't spent the time to try to make a patch.

@eengstrom
Copy link

@rjbs - does the test case fail for you? If yes, then perhaps you can point me in a direction to help contribute a patch, but the tricky part seems to be that it's actually that we are tickling a bug in the Email::Simple module, but should protect against it here.

wolfsage added a commit to wolfsage/email-mime that referenced this issue May 20, 2016
…s#14)

Per RFC 1341, section 7.2

  https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

  A body part is NOT to be interpreted as actually being an RFC 822 message.
  To begin with, NO header fields are actually required in body parts. A
  body part that starts with a blank line, therefore, is allowed and is a
  body part for which all default values are to be assumed. In such a case,
  the absence of a Content-Type header field implies that the encapsulation
  is plain US-ASCII text.
@wolfsage
Copy link
Contributor Author

Possible fix attached

wolfsage added a commit to wolfsage/email-mime that referenced this issue Aug 2, 2016
…rts.

Per RFC 1341, section 7.2

  https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

  A body part is NOT to be interpreted as actually being an RFC 822 message.
  To begin with, NO header fields are actually required in body parts. A
  body part that starts with a blank line, therefore, is allowed and is a
  body part for which all default values are to be assumed. In such a case,
  the absence of a Content-Type header field implies that the encapsulation
  is plain US-ASCII text.
wolfsage added a commit to wolfsage/email-mime that referenced this issue Aug 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants