Description: ------------ When composing a MIME email with a text and HTML portion and attaching HTML Images, the text portion of the email does not display properly in a client that does not support HTML email. If the same email is send without including HTML Images, the text portion works correctly. Test script: --------------- I have asked a question with test code on Stack Overflow. You can see the code and message source there: http://stackoverflow.com/questions/6141085/when-using-pear-mail-mime-the-text-portion-doesnt-work-when-attaching-html-imag Expected result: ---------------- I expect the text portion of the email to be displayed when HTML can't be used. Actual result: -------------- The text in the HTML portion is displayed (without tags), but the content in the "text" portion of the MIME email is completely ignored and not displayed. This was testing and confirmed in Thunderbird (view message as text) and in PINE.

This is from your message: Message-id: <20110526153924.0C12120697@smtp.server.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="=_e107860f353617028a0059317ce51c1f" Original-recipient: rfc822;to@address.com Tell me why there is Content-type, MIME-version, Message-id? Should be Content-Type, MIME-Version, Message-Id. So, I think it is not Mail_Mime issue, but maybe SMTP. Print the message source before sending, to be sure.

@alec I've printed the message before it was sent and the headers you listed are indeed upper case before sending but lower case when received. (i.e. Content-Type -> Content-type). However, I'm unsure of how that is relevant? RFC 5322 (http://tools.ietf.org/html/rfc5322) states in Section 2.3: "ABNF strings are case insensitive and the character set for these strings is US-ASCII." Case sensitivity shouldn't cause a problem such as this.

I'm closing this bug report. It turns out it wasn't Mail_mime and it wasn't our SMTP server either. There seems to be an issue with how Mozilla Thunderbird reads MIME messages. In other words, Thunderbird chokes when the case of the ABNF strings aren't upper-case (i.e. Content-Type). Every other mail client we tested worked fine.