857502 - Incorrect display of non-ascii characters in SOME emails

Status: RESOLVED DUPLICATE of bug 855329

(SeaMonkey :: MailNews: Message Display, defect)

Description

[kjell]

Attachment: Source code for a message that displays incorrectly

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120821170930

Steps to reproduce:

Received an email message and viewed it.


Actual results:

The text displays non-ascii characters incorrectly. It happens only for some messages. It started happening rather recently, so I suspect a bug has been introduced in 2.16.2 or 2.16.1 (or possibly somewhat earlier).

I examined the message source, and it's MIME multipart with the first part as text/plain utf-8 base64 encoded. I decoded the base64 data and viewed it. It appears to be correct utf-8 as it displays correctly in Notepad++ in utf-8 mode. It seems that SeaMonkey displays it in "ansi" instead. At least not in utf-8.


Expected results:

The characters should display correctly.

Comment 1

[kjell]

Attachment: Screen dump showing incorrect message display

Comment 2

[Tony Mechelynck [:tonymec]]

IIUC this is a dupe of either bug 594646 or (less probably) bug 855329. It's hard to tell because the Content-Transfer-Encoding=base64 makes the message source non-human-readable.

I can reproduce the problem with the first attachment: my browser tries to display it in Windows-1252, which is incorrect. Setting it manually to "View → Character Encoding → Unicode (UTF-8)" makes the problem go away.

Kjell: A workaround (not very pretty but better than nothing) consists of displaying the problematic emails using "View → Message Body As → Simple HTML" in SeaMonkey Mail (or in Thunderbird, which has a similar problem). You can still use "Original HTML" for messages which don't have this problem.

You say you decoded the base64. Does the HTML include a <meta> tag with, as attributes, Content= first and http-equiv="Content-Type" afterwards? If it does, then this is an instance of bug 594646.

Comment 3

[andré]

I had a similar problem, where only certain email messages didn't correctly display utf-8.
Other users of thunderbird/seamonkey (and other email agents) could correctly display the same messages.  (Which were from a mailing list.)
It turned out that the headers of the email messages neglected to specify the encoding, and my particular email service replaced the non-ascii codes with an X.
So maybe the same thing is happening in this case ?

If you are definitely receiving unaltered encoding (but just not specified), try setting the default display to utf-8.
( preferences / email / encoding / message display )
It originally is something else.  In the past, that corrected a problem I had displaying utf-8.

Comment 4

[kjell]

@andré: This is not the same case. In "my" case a correct character encoding is specified.

Comment 5

[kjell]

@Tony Mechelynck: This is the exact content of the first base64 segment (between ===, in UTF-8 encoding):
===
Jag kollar imorgon när jag jobbar. Kommer du imorrn?

Skickat från min iPhone

3 apr 2013 kl. 08:32 skrev Kjell Rilbe <[e-mail]<mailto:[e-mail]>>:

Jo, angående det där med att sales-breven studsar, så har jag kommit en bit framåt.

Jag har fixat allt som jag har sett att Google rekommenderar för att breven inte ska tolkas som spam, och det har inte hjälpt. Men förhoppningsvis ökar det chanserna att andra mottagare (kundernas e-postservrar och e-postklienter) inte tolkar breven som spam.

Det finns en sorts signering som vi skulle kunna lägga till som en extra sådan åtgärd, men jag vet i dagsläget inte hur det går till.

Igår fick jag däremot svar från Googles support, och lyckades ställa in [e-mail]<mailto:[e-mail]> att inte göra någon spam-filtrering alls. Därmed bord problemet vara löst, och test-brevet jag skickade igår kväll har i alla fall inte studsat.

Tacksam om ni som fått testbrevet svarar på det så jag kan få bekräftat att det gått fram.

Vi får se under dagen om sales-breven slutar studsa också.

Mvh,
Kjell

--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: [e-mail]<mailto:[e-mail]>
Telefon: [phone]
Mobil: 0733-44 24 64
===

The second base64 segment has these contents (again between === and utf-8 encoding):
===
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Jag kollar imorgon när jag jobbar. Kommer du imorrn?<br><br>Skickat från min iPhone</div><div><br>3 apr 2013 kl. 08:32 skrev Kjell Rilbe &lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;:<br><br></div><blockquote type="cite"><div>
  

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  
  
    Jo, angående det där med att sales-breven studsar, så har jag kommit
    en bit framåt.<br>
    <br>
    Jag har fixat allt som jag har sett att Google rekommenderar för att
    breven inte ska tolkas som spam, och det har inte hjälpt. Men
    förhoppningsvis ökar det chanserna att andra mottagare (kundernas
    e-postservrar och e-postklienter) inte tolkar breven som spam.<br>
    <br>
    Det finns en sorts signering som vi skulle kunna lägga till som en
    extra sådan åtgärd, men jag vet i dagsläget inte hur det går till.<br>
    <br>
    Igår fick jag däremot svar från Googles support, och lyckades ställa
    in <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> att inte göra någon
    spam-filtrering alls. Därmed bord problemet vara löst, och
    test-brevet jag skickade igår kväll har i alla fall inte studsat.<br>
    <br>
    Tacksam om ni som fått testbrevet svarar på det så jag kan få
    bekräftat att det gått fram.<br>
    <br>
    Vi får se under dagen om sales-breven slutar studsa också.<br>
    <br>
    Mvh,<br>
    Kjell<br>
    <pre class="moz-signature" cols="72">-- 
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Telefon: [phone]
Mobil: 0733-44 24 64
</pre>
  

</div></blockquote></body></html>
===

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to kjell from comment #5)
> @Tony Mechelynck: This is the exact content of the first base64 segment
> (between ===, in UTF-8 encoding):
> ===

This looks like plaintext and shouldn't matter

> ===
> 
> The second base64 segment has these contents (again between === and utf-8
> encoding):
> ===
> <html><head><meta http-equiv="content-type" content="text/html;
--------------^^^^^^1111111111111111111111111^2222222222222222222
> charset=utf-8"></head><body dir="auto"><div>Jag kollar imorgon när jag
--22222222222222^

This is not bug 594646. There is also a Content-Type header to that HTML part so it does "specify a single charset twice" as in bug 855329.

> jobbar. Kommer du imorrn?<br><br>Skickat från min iPhone</div><div><br>3 apr
> 2013 kl. 08:32 skrev Kjell Rilbe &lt;<a
> href="mailto:[e-mail]">[e-mail]</a>&gt;:
> <br><br></div><blockquote type="cite"><div>
>   
> 
>     <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
------^^^^^
This should not appear in the <body> part of an HTML message.

>   
>   
>     Jo, angående det där med att sales-breven studsar, så har jag kommit
>     en bit framåt.<br>
>     <br>
>     Jag har fixat allt som jag har sett att Google rekommenderar för att
>     breven inte ska tolkas som spam, och det har inte hjälpt. Men
>     förhoppningsvis ökar det chanserna att andra mottagare (kundernas
>     e-postservrar och e-postklienter) inte tolkar breven som spam.<br>
>     <br>
>     Det finns en sorts signering som vi skulle kunna lägga till som en
>     extra sådan åtgärd, men jag vet i dagsläget inte hur det går till.<br>
>     <br>
>     Igår fick jag däremot svar från Googles support, och lyckades ställa
>     in <a class="moz-txt-link-abbreviated"
> href="mailto:[e-mail]">leveranskopia@foretagskontakt.
> se</a> att inte göra någon
>     spam-filtrering alls. Därmed bord problemet vara löst, och
>     test-brevet jag skickade igår kväll har i alla fall inte studsat.<br>
>     <br>
>     Tacksam om ni som fått testbrevet svarar på det så jag kan få
>     bekräftat att det gått fram.<br>
>     <br>
>     Vi får se under dagen om sales-breven slutar studsa också.<br>
>     <br>
>     Mvh,<br>
>     Kjell<br>
>     <pre class="moz-signature" cols="72">-- 
> --------------------------------------
> Kjell Rilbe
> DataDIA AB
> E-post: <a class="moz-txt-link-abbreviated"
> href="mailto:[e-mail]">[e-mail]</a>
> Telefon: [phone]
> Mobil: 0733-44 24 64
> </pre>
>   
> 
> </div></blockquote></body></html>
> ===

I'm tentatively duplicating this to bug 855329. Feel free to REOPEN with an appropriate comment if, after bug 855329 gets FIXED, you still see this bug in a SeaMonkey build containing the fix.

The following describes my current build of SeaMonkey, where I can reproduce the bug with attachment 732735 [details]:
Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20a1 ID:20130421003001 c-c:1637ab8d5a01 m-c:0d50cb959c46