1440017 - Character substitutions with question marks in HTML emails

Status: RESOLVED DUPLICATE of bug 1435903

(MailNews Core :: Networking: SMTP, defect)

Description

[Craig]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2
Build ID: 20180205075051

Steps to reproduce:

Sending HTML email of copied quotes from a page on the BBC website:

http://www.bbc.com/culture/story/20170303-eight-words-that-changed-the-way-we-think 

using SM 2.49.2.


Actual results:

Single quotes "'", double quotes '"' and hyphens "-" are being converted to multiple question marks when viewed in both the Yahoo and Gmail web browsers.

I reverted to SM 2.49.1 to see if the problem was solely with 2.49.2, but it wasn't. The problem also occurred when sending from 2.49.1. 

Sas requested to try this in Thunderbird as well, but I don't have it installed.




Expected results:

The quotes should render as originally in online browsers.

My guess was that BBC was intentionally using nonstandard 'lookalike' characters, to make copying more difficult, with characters from non-English character sets that the online browsers couldn't handle.

Comment 1

[Frank-Rainer Grahl (:frg)]

I am not sure what you mean by sending email. I assumed this was a mail compose problem but it seem that it is a webmail frontend problem or just some copy / paste error. Could you add a step by step guide or add some screenshots.

Comment 2

[Craig]

Attachment: bugdemo1.png

Comment 3

[Craig]

See the screen capture above. First, the first two paragraphs of the article as captured. Second, how otherwise-unformatted text appears in the gmail web browser after being sent by SM 2.49.2.

Comment 4

[Craig]

FYI, to cover the bases I tried the same thing again in non-HTML email. No problem there, everything comes through intact.

Comment 5

[Craig]

There is now the added complication (in the thread on mozilla.support.seamonkey in reply to Lemuel Johnson) that changing the smtp server to something other than smtp.att.yahoo.com changes the outcome. To which I will add that when I tried changing my SM 2.49.2 smtp server to smtp.gmail.com it for whatever reason failed...it still used smtp.att.yahoo.com.com and same outcome.

Comment 6

[Craig]

Reinstalling SM 2.48 has solved all of my problems mentioned above and as detailed in the mozilla.support.seamonkey thread.

Comment 7

[Frank-Rainer Grahl (:frg)]

Your bug report is a little confusing. How do you sent and email from the website? I assume it is the problem covered here:

http://forums.mozillazine.org/viewtopic.php?f=39&t=3038519&p=14792921#p14792921

This seems to indicate a yahoo server problem which can be overcome by setting mail.strictly_mime to true.

Comment 8

[Craig]

I never send emails from either the Yahoo or Gmail web mail. My sole use for them is proofing html emails sent from SM to dissimilar online browsers to try and hold down formatting glitches for the intended recipient, who will be using online email. (No, I'm not a marketer).

Setting mail.strictly_mime to true does indeed seem to work. Hurrah! And I am now able to set the gmail smpte server as default and have SM use it. How that is related to mail.strictly_mime or if it is, I admit ignorance.

Finally, I looked at mail.strictly_mime in 2.48 before uninstalling, and it was set to false. But then, someone on mozilla.support.seamonkey thinks Yahoo has suddenly changed their settings. So I throw up my hands...

I thank you for your attention to my problem, and I do not envy SM devs for having to keep track of all of this and more all at the same time.

Comment 9

[Jorg K (CEST = GMT+2)]

This is a current problem with all e-mail services provided by AT&T, Yahoo, BellSouth, sbcglobal, etc.
Further reading:
https://forums.yahoo.net/t5/Sending/Yahoo-SMTP-server-advertising-8bit-capability-incorrectly-and/m-p/460316

Workaround: Set preference mail.strictly_mime to true.

Note: Multiple spaces or tabs get converted to non-breaking spaces and they get transmitted as 8bit characters which don't get transmitted properly.