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. >
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);
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.
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.
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);
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
