Created attachment 560872 [details] ThunderBird-return-from-recipient failure.pdf User Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 Build ID: 20110905121216 Steps to reproduce: Email bounced from recipient server (see enclosure) giving explanation character set ISO 8859-10. Runs ThunderBird 6.02 for OS/2 / eComStation. Problem was not present for version 3.x. Actual results: See enclosure
ISO 8859-10 is an official character encoding. - http://en.wikipedia.org/wiki/ISO/IEC_8859-10 The used character encoding is chosen based on the used characters in the email. There should not be a difference between TB3.x and TB 6.02 You can override the used character encoding in the message composition under tools/Character Encoding
Thanks for a very rapid answer. The problem is that changing the character encoding makes the Scandinavian letter æ, ø and å to come up garbled on the recipient's email. But maybe this is the wrong address for this question -- it is servers declining messages if they cannot recognize standard character sets that is the problem?
TB uses the "lowest" possible character encoding for the used characters. ISO8859-1 is used for emails that contain for example the german "ä". The € isn't in 8859-1 and TB has to switch to 8859-15 if I use it an email with german characters. In your case TB switches to iso8859-10 if you use æ, ø and å. BTW: A good overview of ISO8859 can be found here http://en.wikipedia.org/wiki/ISO/IEC_8859 You can try to switch to Unicode UTF-8 instead. That should contain all characters that we in Europe are using. Yes, it's a server problem and it's the first time that I hear that a server rejects an email based on the character encoding. Using UTF-8 as example is only a workaround for the stupid server.
Problem solved. By setting character set 8859-1, the problem disappeared, and recipients of emails still got the Nordic letters æøå displaying properly. It turns out that ThunderBird switches code set when it discovers special characters, but that this is not detected by mailservers with restrictions on accepted character sets. Thanks Matti for the tip that pointed me in the right direction :-)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.