Hi,
I am having a problem with my DirectAdmin Server,
Host: Centos 6 32 bits.

When some body send an email to any email account in my directadmin server with unicode fonts.
They can read it but when they reply the email with a unicode character the reader can not read it.
Example :

I check it out and see my server use &#unicode;

Could somebody help me to change the encoding in my server.
Thanks

Hi there,

your description of the problem is very confusing, I can't really follow you.

Unicode is not a font; it's a character set. And by specification, web documents and e-mails always use Unicode or a subset thereof.

That sample tells us nothing - except that whoever composed the e-mail message used HTML-style numerical character references (NCRs), which is a concept of HTML and is totally out of place in e-mail. Unless we're talking about HTML-formatted mails, which is a nuisance of its own and would deserve explicit mentioning.

This is nothing that could be set "on your server", it's a per-user setting of the mail client. And especially, it might not be a problem on your end, but at the sender's end. So in order to help you, I'm afraid I need a more detailed description of the problem.

[X] Doc CPU

I have attached the origin email and some lines in the mainlog send from my directadmin server.
I can not read it using my gmail account because it did not display the character correctly.

Attached Thumbnails

 

Hi there,

I'm sorry, but this doesn't clarify much for me. That's a snippet from some log file, and apparently it logs (among other things) mail messages being sent or received. No idea from who, I just guess it's some daemon that sends status messages per mail.

But does the weird mix of letters make sense to you? Is it actually text in some language? To me, it looks like random characters. But then I'm aware that the world is full of languages I don't understand.
Anyway, whoever creates and sends these messages, makes the mistake of putting HTML-style character references into it where they don't belong. No receiving client would have any reason to resolve these character references. It's like putting Chinese symbols into an English text because you think it looks fancy, and expect that people can read it correctly.

So your task should be: Find out which process creates these garbled messages, and configure it properly, so it doesn't generate these character references any more, but instead puts the desired character directly into the message.

Use a decent mail client. ;-)

[X] Doc CPU

1 members found this post helpful.

Thanks for your support and so sory when making you feel confusing,
I use SquirrelMail to compose those emails.
The content is a vietnamese string(Unicode).
I use the EXIM at MTA.
I can not figure out which way to find out the daemons creates these garbled messages.

Attached Thumbnails

   

Hi there,

okay, now that could be helpful information - if only I knew Squirrel Mail and Exim better.

I have a theory, though: What strikes me is that all the garbled characters have a double diacritic mark in the original representation, while the others have only one diacritic mark or none at all - they could as well appear in any Western script. My theory is that Squirrel Mail is using a character encoding that limits it to a basic character set, something like the ISO-8859 family maybe, but it has a built-in way to circumvent this limit, which is escaping these characters as HTML character references. This is an appropriate strategy where the context is HTML, but not in a non-HTML context like mail or plain text.

If you can dig into Squirrel Mail and find a way to make it use UTF-8 as its standard character encoding, you might be done. Exim is probably innocent here; as an MTA, it should only pass the message along without modifying its contents.

Maybe that hint of mine was wrong. I just thought these messages came from a program or a script running "underground". I didn't think of it as a hand-typed message.

So it's Vietnamese. Okay, then it's not a surprise that it looks completely alien to me. Probably German would look just as strange to you.

[X] Doc CPU

1 members found this post helpful.

Thanks so much.
The problem has fixed but just a half part of my problem.
Changing the Default Charset in SquirreMail config(./conf.pl) to UTF-8.
Some auto Warnings send directly(Dovecot) to my admin email also has this problem.
I am working around it.

Data saved in config.php
Press enter to continue...
SquirrelMail Configuration : Read: config.php (1.4.0)
---------------------------------------------------------
Language preferences
1. Default Language : en_US
2. Default Charset : utf-8
3. Enable lossy encoding : false

R Return to Main Menu
C Turn color on
S Save data
Q Quit