On 2017-11-09, Jasen Betts wrote:
> On 2017-11-09, Jeremy Harris wrote:
>> On 08/11/17 21:15, Yves Goergen wrote:
>>> But the problem is that Exim doesn't talk to the MySQL server with UTF-8
>>> so it prevents using all that stuff. Instead, it uses some 8-bit
On 2017-11-09, Jeremy Harris wrote:
> On 08/11/17 21:15, Yves Goergen wrote:
>> But the problem is that Exim doesn't talk to the MySQL server with UTF-8
>> so it prevents using all that stuff. Instead, it uses some 8-bit
>> encoding. I can see this in the reply message: It
On 2017-11-09, Jan Ingvoldstad via Exim-users wrote:
> I don't know if this has any relevance, but please note that the MySQL
> "utf8" character set is not UTF-8.
>
> It's the subset of UTF-8 that consists of up to three-byte UTF-8
> glyph. If you have a four-byte UTF-8
That's interesting, and it really does work! Thank you.
It probably has the side effect of reconfiguring the MySQL connection
for subsequent queries, after the first Sieve filter was fetched from
the database, but since no other part uses characters that would be
different in the default and
Am 09.11.2017 um 16:08 schrieb Cyborg:
> Hi,
>
> this is part of a virus email :
>
>
> --439767554304687794273679
> Content-Type: application/msword;
> name="ARY7411 - 08.11.2017.doc"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> filename="ARY7411 -
On 09/11/17 15:08, Cyborg wrote:
> --439767554304687794273679
> Content-Type: application/msword;
> name="ARY7411 - 08.11.2017.doc"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> filename="ARY7411 - 08.11.2017.doc"
>
>
Yes, it's the letter "ü" as I already showed, quoted-printable-encoded.
And it's only one byte. If the message were properly UTF-8-encoded,
there would be two bytes: =C3=BC This tells me that Exim generated a
message with Latin1 encoding (western default) instead of UTF-8. And I
can only
--On Thursday, November 9, 2017 14:10 + Jeremy Harris
wrote:
> On 08/11/17 21:15, Yves Goergen wrote:
>> But the problem is that Exim doesn't talk to the MySQL server
>> with UTF-8 so it prevents using all that stuff. Instead, it
>> uses some 8-bit encoding. I can see
Hi,
this is part of a virus email :
--439767554304687794273679
Content-Type: application/msword;
name="ARY7411 - 08.11.2017.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="ARY7411 - 08.11.2017.doc"
On 08/11/17 21:15, Yves Goergen wrote:
> But the problem is that Exim doesn't talk to the MySQL server with UTF-8
> so it prevents using all that stuff. Instead, it uses some 8-bit
> encoding. I can see this in the reply message: It contains parts like
> =FC for "ü" where it should be at least two
I don't know if this has any relevance, but please note that the MySQL
"utf8" character set is not UTF-8.
It's the subset of UTF-8 that consists of up to three-byte UTF-8
glyph. If you have a four-byte UTF-8 glyph, this fails.
MySQL failed to fix this issue, and instead introduced another
That looks promising, but doesn't have any effect yet.
I've added the file /etc/mysql/conf.d/exim-utf8.cnf, as included from
/etc/mysql/my.cnf, with the following content:
[exim]
character_set_client=utf8
Then I restarted Exim. The autoresponder e-mail still doesn't contain
UTF-8 encoded
12 matches
Mail list logo