User Agent: Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17 Build ID: 20130331213155 Steps to reproduce: Tried to view an email that contained greek letters. Actual results: The greek characters of the email content are presented with non understandable characters. However, the subject of the email, which also contained greek letters, is fully shown in greek letters. I still couldn't view the greek characters by changing to all available greek encodings and also unicode and UTF. After experimenting with various emails sent to Seamonkey from outlook express 6 (win xp), which is the origin of the unreadable emails, I found out that only HTML formatted (not plain text) emails are unreadable. This has been happening for the last two months (3-5 SM updates have been installed during this period). Expected results: I should at least have been able to view the greek letters by changing to the proper encoding.
This sounds like a duplicate of bug 594646. That bug happens in some HTML messages but not in plaintext messages, and "View → Message Body As → Simple HTML", or replying to the message, shows the text as it should be. Of course, "Original HTML" can still be used for messages not affected by the bug.
The solution "View → Message Body As → Simple HTML" works for all emails that were unreadable. Thanks!
(In reply to firstname.lastname@example.org from comment #2) > The solution "View → Message Body As → Simple HTML" works for all emails > that were unreadable. > > Thanks! Thanks for the info. Could you please attach one such message ("File → Save As → File" on the message, then "Add an attachment" just below the heading part of the Bugzilla page, and set the content type manually to message/rfc822) so that we could check whether this is an instance of bug 594646?
Created attachment 734478 [details] Test email written in greek and latin characters
<META content=3D"text/html; charset=3Diso-8859-7" = http-equiv=3DContent-Type> or after resolving the quoted-printable: <META content="text/html; charset=iso-8859-7" http-equiv=Content-Type> Yes, that is bug 594646 (content= first and http-equiv=Content-Type thereafter).