Email::MIME walk_parts doesn't walk all my parts
Hi, I'm using Email::MIME to iterate through all parts of a multipart email, with the following code, which I have somewhat copied from the manual Email::MIME manual. use Email::MIME; my $email; { local $/; $email = Email::MIME->new(); } $email->walk_parts(sub { my ($part) = @_; warn($part->content_type . ": " . $part->parts); }); This little snippet is supposed to read an email from stdin and print the content-types of all parts (plus the amount of subparts that it has). Now for most emails this works fine, but not so for attached email. For this email it only sees the first part: multipart/mixed; boundary="=_Part_13986_26026450.1275360964578": 1 I would expect walk_parts to also iterate through the multipart/related, text/html and image/gif parts, but it does not. It may very well be that this email is malformed in some way, but this is the way I received it (I erased most of the actual content to make it shorter but the result is the same). Thunderbird has no problem parsing it, but perhaps Tbird is somewhat tolerant. Kind regards, Erik. P.S. I use the latest version of Email::MIME from CPAN and also the latest versions of the following dependencies: Email::Address Email::MessageID Email::MIME::ContentType Email::MIME::Creator Email::MIME::Encodings Email::MIME::Header Email::MIME::Modifier Email::Simple::Creator Perl itself and all other dependencies that may be are from Fedora 12 x86_64. email3.eml Description: application/mimearchive
Re: Email::MIME walk_parts doesn't walk all my parts
> This looks like an incredibly stupid bug based on the incredibly stupid > ->parts > method. Its behavior is really lame. > > I'm afraid I don't have a lot more time to look at this right now, but I'd > play > around with tweaking walk_parts (in Email::MIME) to use ->subparts instead, > which is a lot saner. > > If that fixes this, it's probably a welcome patch. Thanks for the report. Yeah that fixes this indeed, thank you very much. Please find attached the patch to MIME.pm with this fix. Kind regards, Erik. --- Email/MIME.pm-orig 2009-12-23 17:35:11.0 +0100 +++ Email/MIME.pm 2010-06-03 23:39:39.334928669 +0200 @@ -712,9 +712,9 @@ $walk = sub { my ($part) = @_; $callback->($part); -if ($part->parts > 1) { +if ($part->subparts > 0) { my @subparts; - for ($part->parts) { + for ($part->subparts) { push @subparts, $walk->($_); } $part->parts_set(\...@subparts);
Using Email::MIME to convert a plain email to a multipart
Hi, I'm trying to use Email::MIME to convert a plain email (not MIME) to a MIME multipart mail. According to the manual I can use the parts_set method for this purpose because it'll convert a plain email to multipart if necessary. So I add the original body as part 1 and a random second part as follows: $email = Email::MIME->new(); my $part1 = Email::MIME->create( attributes => { content_type => "text/plain" }, body => $email->body); my $part2 = Email::MIME->create( attributes => { content_type => "text/plain" }, body => 'part 2'); $email->parts_set([ $part1, $part2 ]); print $email->as_string(); Now what this does is not exactly as I expected. The result is indeed a multipart email with both parts. However looking closely I noticed that each part has both a Date and a MIME-Version header. Those I did not expect. Moreover I also noticed that the email headers are appended by a "Content-Type: multipart/mixed" header, but not with a MIME-Version header. So I have two MIME-Version headers instead of one, but neither are in the right place. Now I can understand this to some degree, since I use Email::MIME->create() to create the parts. The documentation of create() does specify that a Date-header will be added, since it's mandatory (at least, within the context of an email itself). So even though methods like parts() do return the parts as Email::MIME instances, apparently the create() method is not the right way to create a simple part, without automatically creating headers that are only relevant for the email itself. So... how does one create simple parts? Or if this is not the way at all: how does one convert a non-MIME email to MIME multipart? Kind regards, Erik.
Fwd: Using Email::MIME to convert a plain email to a multipart
Hi, I'm running into several unexpected behaviours from Email::MIME after using parts_set and its wrapper parts_add. 1) Most notably changes to parts have no effect after they've been added to the email, for instance in the example below, if I were to append the following: $part2->header_set("Foo", "Bar"); Now print $part2->as_string(); will print the part including the new header, but print $email->as_string(); will print the email containing that part without its new header. 2) When implicitly converting a single part message to multipart by using parts_add(), the original body will be converted into a part. However this part will also contain all original headers from the email itself. Last but not least, I should note that I am merely guessing what the recommended way is to convert a non-MIME or single part MIME email to multipart. The only reference I could find in the manual is in the description of the parts_set method: "Replaces the parts for an object. Accepts a reference to a list of Email::MIME objects, representing the new parts. If this message was originally a single part, the Content-Type header will be changed to multipart/mixed, and given a new boundary attribute." Well that seems clear enough. Nevertheless it would help if someone could indicate wether or not this is indeed the recommended way to convert a single part mail to multipart. Also I'm also just guessing that after adding parts one should still be able to change them. This is not explicitly stated in the documentation (neither is the opposite), so it would also help if someone could confirm that this is indeed the expected behaviour. Thank you in advance and kind regards, Erik. Original Message Subject: Using Email::MIME to convert a plain email to a multipart Date: Fri, 04 Jun 2010 22:51:20 +0200 From: Erik Logtenberg To: pep@perl.org Hi, I'm trying to use Email::MIME to convert a plain email (not MIME) to a MIME multipart mail. According to the manual I can use the parts_set method for this purpose because it'll convert a plain email to multipart if necessary. So I add the original body as part 1 and a random second part as follows: $email = Email::MIME->new(); my $part1 = Email::MIME->create( attributes => { content_type => "text/plain" }, body => $email->body); my $part2 = Email::MIME->create( attributes => { content_type => "text/plain" }, body => 'part 2'); $email->parts_set([ $part1, $part2 ]); print $email->as_string(); Now what this does is not exactly as I expected. The result is indeed a multipart email with both parts. However looking closely I noticed that each part has both a Date and a MIME-Version header. Those I did not expect. Moreover I also noticed that the email headers are appended by a "Content-Type: multipart/mixed" header, but not with a MIME-Version header. So I have two MIME-Version headers instead of one, but neither are in the right place. Now I can understand this to some degree, since I use Email::MIME->create() to create the parts. The documentation of create() does specify that a Date-header will be added, since it's mandatory (at least, within the context of an email itself). So even though methods like parts() do return the parts as Email::MIME instances, apparently the create() method is not the right way to create a simple part, without automatically creating headers that are only relevant for the email itself. So... how does one create simple parts? Or if this is not the way at all: how does one convert a non-MIME email to MIME multipart? Kind regards, Erik.
Fwd: Re: Email::MIME walk_parts doesn't walk all my parts
Hi, Since this change, inspired by Ricardo Signes, fixes an obvious bug in Email::MIME, I'd like to request this patch be pushed into git. Also a new release of Email::MIME containing this fix would be nice. Kind regards, Erik. Original Message Subject: Re: Email::MIME walk_parts doesn't walk all my parts Date: Thu, 03 Jun 2010 23:43:24 +0200 From: Erik Logtenberg To: pep@perl.org > This looks like an incredibly stupid bug based on the incredibly stupid > ->parts > method. Its behavior is really lame. > > I'm afraid I don't have a lot more time to look at this right now, but I'd > play > around with tweaking walk_parts (in Email::MIME) to use ->subparts instead, > which is a lot saner. > > If that fixes this, it's probably a welcome patch. Thanks for the report. Yeah that fixes this indeed, thank you very much. Please find attached the patch to MIME.pm with this fix. Kind regards, Erik. --- Email/MIME.pm-orig 2009-12-23 17:35:11.0 +0100 +++ Email/MIME.pm 2010-06-03 23:39:39.334928669 +0200 @@ -712,9 +712,9 @@ $walk = sub { my ($part) = @_; $callback->($part); -if ($part->parts > 1) { +if ($part->subparts > 0) { my @subparts; - for ($part->parts) { + for ($part->subparts) { push @subparts, $walk->($_); } $part->parts_set(\...@subparts);
Re: things need co-maint
There are a couple of modules on that list that I do use and I would be willing to do some maintenance on if and when required. Some mail modules I use are: Email-Address Email-MessageID Email-MIME Email-MIME-ContentType Email-MIME-Encodings Email-MIME-Modifier Email-Send Email-Simple Mail-DKIM Mail-SPF MailTools MIME-Lite Of this list of modules I use, Email-Send and MIME-Lite are on your list of modules that need a new (co)maintainer. Could you incidate if these modules currently have other maintainers, and if there are open bugs (i.e. there is already maintenance that needs to be done). Thanks, Erik. On 20-08-14 02:57, Ricardo Signes wrote: > * Geoffrey Leach [2014-08-19T19:54:44] >> Does this imply the passing of the Perl Email Project? Perhaps you ncould >> elaborate. > > The PEP, as far as I am concerned, is a non-thing. It is a name describing > nothing that exists. In about five years, the only thing that has happened > associated with its name have been releases of software once under its > umbrella, done by me, linking to a single static web page. > > If someone wants to do something with the name, great. Otherwise, nothing is > being killed off that was not already moldering. >