User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.5 (KHTML, like Gecko) Chrome/16.0.891.0 Safari/535.5 Steps to reproduce: Opened mail from Dell. Actual results: Message from DELL with both TEXT and HTML part is only shown as TEXT. Expected results: HTML part should be shown.

This message is malformed. The text/html part should come *after* the text/plain part. From RFC 2046: > In general, the best choice is the LAST part of a type supported by the recipient > system's local environment.

Mail structure. > Content-Type: multipart/alternative; > boundary=--boundary_315424_148fd605-6cb4-4519-b11b-e4ba8bedf582 > > ----boundary_315424_148fd605-6cb4-4519-b11b-e4ba8bedf582 > Content-Type: text/html; charset=utf-8 > ----boundary_315424_148fd605-6cb4-4519-b11b-e4ba8bedf582 > Content-Type: text/plain; charset=utf-8 > ----boundary_315424_148fd605-6cb4-4519-b11b-e4ba8bedf582-- Most preferred part in multipart/alternative is text/plain part placed by sender at bottom in multipart/alternative, so Tb selects the text/plain part because Tb can understand both text/html and text/plain. If you are saying Tb's bug(flow of Tb's code), dup of many other older bugs opened for same symptom/phenomenon, and is INVALID as Tb works as designed and it's RFC compliant. If you are requesting usability enhancement with malformed/not-well-formed mail, dup of bug 574989 or some other older/newer bugs than that bug which were opened for same symptom/phenomenon.

Duplicate