Re^3: MIME::Lite and Multipart

I still don't understand why the "Type" can't be added by itself.

Just a note before forwarding you to perldoc, the module source code and zwon for further study:

you correctly wrote in the opener: $message->replace(Type=>'multipart/mixed');, and this indeed **works** and changes the mail structure you set with the Type=>... assignment during ->new/->build.

Without an explicite Type, Dumper shows a non-MIME text/plain message. Adding mime parts seems to turn the original body (that you never defined in the opener or Re^4) into our undefined problem mime part, while also turning the Type to multipart/mixed. If my assumption is correct, just setting Data=>"" (and never setting a Type at all) before adding attachments should also avoid the undef bugs.

Comment on Re^3: MIME::Lite and Multipart Download Code

Replies are listed 'Best First'.
Re^4: MIME::Lite and Multipart by zwon (Abbot) on Sep 29, 2009 at 22:28 UTC
you correctly wrote in the opener: `$message->replace(Type=>'multipart/mixed');`, and this indeed works No, that's not correct! It creates multipart/mixed with three parts, and it should be multipart/mixed with two parts one of which multipart/alternative and other is attachment.	[reply] [d/l]
Re^5: MIME::Lite and Multipart by jakobi (Pilgrim) on Sep 29, 2009 at 23:01 UTC
Hmm. Checked with dumper. The (fixed) opener code indeed switches to a 3 part multipart/alternative type, which can be successfully mailed, and mutt by default displays the text part of the 2 'inline' parts, and shows all parts with v. Given the implied structure by the code you're right that a hierarchic MIME structure is probably intended by Analog (attaching $alternatives as a (implicit disposition inline?) MIME part to an outer MIME $message as per your skeleton, zwon). And it is indeed preferrable to merely relying on the inline disposition of the working (sensu code sending email instead of aborting) flattened structure produced Analog's initial code scrap. Assuming that modern-day apps should be capable of parsing more than the most trivial of MIMEs (insert some sarcasm of your choice about mailer software quality). Darn it, I really depend on the missing one or two lines of comments, when comparing 2 more or less working code scraps :/. Eyeing the detail makes me register the more elegant code, but it also makes me consider elegance/simplicity to be just a currently irrelevant attribute for the task at hand. sigh, g'night, Peter	[reply]