Re^4: MIME::Lite and Multipart

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]