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