Hi Erik,

On 06/06/2010 10:02 PM, Erik Logtenberg wrote:
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
$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.

I don't think that way of using Email::MIME is supported. A quick look at the code reveals that parts_set copies the contents of the parts into the parent object.

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

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.

Given the current behavior, I would extract the body and mime type and such from the single part message and use parts_set directly. IMHO, that's what parts_add should do. Right now, it unfortunately just uses the entire original message as the first part.

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.

See above.


Reply via email to