Re^2: problem w/ MIME::Lite and multipart/alternative emails

Replies are listed 'Best First'.
Re^3: problem w/ MIME::Lite and multipart/alternative emails by tirwhan (Abbot) on Jan 23, 2006 at 19:24 UTC
So this is actually a Thunderbird question, not a Perl question, right ;-)? With multipart/alternative you'd expect the client to only show one of the alternative contents (that's what that Content-Type is for). Go to your "View"->"Message body" menu in Thunderbird and fiddle with the settings there, it gives you some options on what you want displayed. There are ten types of people: those that understand binary and those that don't.	[reply] [d/l]
Re^4: problem w/ MIME::Lite and multipart/alternative emails by geektron (Curate) on Jan 23, 2006 at 19:54 UTC
Actually, it's more of a bug with Thunderbird, apparently. I do have my settings so that the original HTML is displayed, but Thunderbird isn't displaying it.	[reply]
Re^3: problem w/ MIME::Lite and multipart/alternative emails by thedoe (Monk) on Jan 23, 2006 at 20:41 UTC
I had this exact same problem when trying to create a program which would email Lotus Notes users. It has been a while, but if I remember correctly the solution was to send the source in the text portion of the message and include the HTML as a multipart attachment. It was something very odd and hacky, but it solved the problem for Notes. If this is something that you truly need to see in Thunderbird, trying doing a combination of attaching one part and putting the other in the base message.	[reply]
Re^4: problem w/ MIME::Lite and multipart/alternative emails by geektron (Curate) on Jan 23, 2006 at 20:44 UTC
actually, i found a solution after searching through the mozillazine.org forums. the order of the MIME types is important to Thunderbird. irritating at best and causes 'broken' emails at worst. the specific link i found to help solve the problem is here	[reply]
Re^5: problem w/ MIME::Lite and multipart/alternative emails by Anonymous Monk on Apr 11, 2014 at 01:46 UTC
I should point out that the order of the alternatives is important as the RFC (RFC2046) says that a user agent should display the last one that they can handle. Any user agent doing otherwise is not MIME compliant. It's up to the sender to decide the preference, and it goes from lowest to highest.	[reply]