You are not logged in.
Hi guys!
I encountered a bug. Some letters were imported to GLPI in the wrong encoding. After viewing the source and debugging I found an error in the logic of code. Mail body can be converted when it is not needed. Bug occurs when IMAP server transmits mail body in UTF-8 but mail subject in other encoding (KOI8-R in my case).
In the method of decodeMimeString the class MailCollector encoding of the last MIME-string saved in the field "charset". This field is used when it is not empty and mail body has not been converted to UTF-8 (see method buildTicket of decodeMimeString class). It looks like a hack for processing bad mails. The field "body_converted" contains a sign saying, that mail body is processed and does not require transcoding. When body is transmitted in UTF-8, the field “body_converted” does not change and in the method “buildTicket” body is converted from encoding of the field "charset" to UTF-8.
The following patch solves the problem:
--- inc/mailcollector.class.php.orig 2012-01-30 00:08:25.000000000 +0400
+++ inc/mailcollector.class.php 2012-01-30 01:29:35.000000000 +0400
@@ -955,6 +955,11 @@
$text = mb_convert_encoding($text, 'utf-8',$param->value);
$this->body_converted=true;
}
+ if ((strtoupper($param->attribute)=='CHARSET')
+ && function_exists('mb_convert_encoding')
+ && strtoupper($param->value) == 'UTF-8') {
+ $this->body_converted=true;
+ }
}
}
return $text;
Patched version (0.80.61) is working without any problems for a month
Offline
Can you please send a mail which cause the encoding issue to testsupportglpi <AT> free <DOT> fr
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Can you please send a mail which cause the encoding issue to testsupportglpi <AT> free <DOT> fr
Unfortunately - not. We use the account on Gmail for the helpdesk, just gmail imap server change the encoding of subject in some case. I can try tonight to reproduce the problem with last version of GLPI and Postfix mail server, if necessary. In this case I will cat to send mail which cause the encoding issue.
Offline
Sorry for long silence. I have sent the mail, which provoke the problem.
Mail body content:
Test message for topic http://www.glpi-project.org/forum/viewt … p?id=28075
Text in russian: тестовое сообщение
Mail imported as:
Test message for topic *link was here, but parcer allow only one link in post*
Text in russian: я┌п╣я│я┌п╬п╡п╬п╣ я│п╬п╬п╠я┴п╣п╫п╦п╣
Offline
i am very sorry,now we are useing the GLPI 0.80.7 ,but still something wrong with the encoding.can you help me?what's the file name that you modified?thanks
Offline
move to rigth section
MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI : Support Contribute References Freshmeat
Offline
Hello, same problem here.
encoding of e-mail windows-1257. Can you provide me fix to this problem?
Offline
Hello, same problem here.
encoding of e-mail windows-1257. Can you provide me fix to this problem?
Did you try apply patch from first message?
Offline
This fix the problem, but not for all clients...
problem still exists.
Offline
This fix the problem, but not for all clients...
problem still exists.
Can you please show a bad mail source.
Offline
Return-Path: <sender@sender.lt>
Delivered-To: sender@sender.lt
Received: from [192.168.16.196] (unknown [XXX.XXX.XXX.XX])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
(Authenticated sender: sender@sender.lt)
by ssender.sender.com(Postfix) with ESMTPSA id 0BC5213F558;
Mon, 19 Aug 2013 09:44:24 +0300 (EEST)
Message-ID: <5211BEBD.4090805@sender.lt>
Date: Mon, 19 Aug 2013 09:44:13 +0300
From: =?windows-1257?Q?Karolis_Did=FEiulis?= <sender@sender.lt>
Organization: sender
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Tomas Katkevicius <sender@tomas.lt>
CC: Povilas <sender@sender.lt>
Subject: =?windows-1257?Q?d=EBl_testing=2Ensoft=2Elt?=
Content-Type: text/plain; charset=windows-1257; format=flowed
Content-Transfer-Encoding: 8bit
and mail: gavom iš valdžios nurodymą, kad turim perkelti naują puslapį
Offline
GLPI 0.84.3
same problem with koi8-r subject, patch didn't helped.
could anybody please tell how to fix it?
headers of the same letter are below:
From prvs=048ea0744=it@manpower.ru Mon Dec 09 17:47:19 2013
Return-path: <prvs=048ea0744=it@manpower.ru>
Authentication-Results: mxs.mail.ru; spf=pass (mx176.mail.ru: domain of manpower.ru designates 81.23.9.72 as permitted sender) smtp.mailfrom=prvs=048ea0744=it@manpower.ru smtp.helo=mail.manpower.ru
Received-SPF: pass (mx176.mail.ru: domain of manpower.ru designates 81.23.9.72 as permitted sender) client-ip=81.23.9.72; envelope-from=prvs=048ea0744=it@manpower.ru; helo=mail.manpower.ru;
Received: from [81.23.9.72] (port=3941 helo=mail.manpower.ru)
by mx176.mail.ru with esmtp (envelope-from <prvs=048ea0744=it@manpower.ru>)
id 1Vq1B7-0003QE-Cl
for mail1981@inbox.ru; Mon, 09 Dec 2013 17:47:19 +0400
X-Mru-BL: 0:0:1033
X-Mru-PTR: mail.manpower.ru
X-Mru-NR: 1
X-Mru-OF: unknown (Ethernet or modem)
X-Mru-RC: RU
Received: from zoom.mpmsk.corp (HELO mail.manpower.ru) ([172.16.10.32])
by mail.manpower.ru with ESMTP; 09 Dec 2013 17:50:38 +0400
Received: from ZVENO.mpmsk.corp ([fe80::19d:5c2f:93c:bc5e]) by ZOOM.mpmsk.corp
([172.16.10.32]) with mapi id 14.02.0318.001; Mon, 9 Dec 2013 17:47:15 +0400
Content-Type: multipart/mixed;
boundary="_000_A7CC6F9414E8AB49B8657ACCB74F35E51D03CAE5ZVENOmpmskcorp_"
From: "Chekmez, Andrey" <it@manpower.ru>
To: "'mail1981@inbox.ru'" <mail1981@inbox.ru>
Subject: =?koi8-r?B?0NLP18XSy8E=?=
Thread-Topic: =?koi8-r?B?0NLP18XSy8E=?=
Thread-Index: Ac705SeX1kB+LXZ5T7e6auU1ODnLFw==
Date: Mon, 9 Dec 2013 13:47:14 +0000
Message-ID: <A7CC6F9414E8AB49B8657ACCB74F35E51D03CAE5@ZVENO.mpmsk.corp>
Accept-Language: ru-RU, en-US
Content-Language: ru-RU
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: <A7CC6F9414E8AB49B8657ACCB74F35E51D03CAE5@ZVENO.mpmsk.corp>
x-originating-ip: [172.16.7.77]
MIME-Version: 1.0
X-Spam: Not detected
X-Mras: Ok
X-DMARC-Policy: no
Offline