Open schieffahrer opened 4 months ago
cedric-anne
commented
4 months ago Hi,
Could you please provide an email, into the .eml format, that can be used to reproduce the issue ? We need the email generated in your step 2 (the email that contains a .msg file as attachement).
schieffahrer
commented
4 months ago How could I send the data without running into data protection problems? There is some personal data in the text.
I was able to find out something else in the meantime: After the MSG file is sent to the ticket system, the ticket system replies with the ticket number and the content. The attachment is also included here. This is then called "msg_1_wg-your-scim-token-will-expire-soon-testmail.EML.msg" and the file type is a MSG file and not an EML file. It is the same file that I sent. When I open the ticket system, the file is called "msg_1_wg-your-scim-token-will-expire-soon-testmail.EML" and has been converted to EML. The sender therefore only sees their own file but not the file in the ticket system.
cedric-anne
commented
4 months ago How could I send the data without running into data protection problems?
It is not possible in the community support context. Either you have to ask for professionnal support, either you have to reproduce the issue using an email account created for this purpose only.
plbv
commented
4 months ago I am experiencing almost the same issue with HTML code in email, using GLPI 10.0.14 and the IMAP collector.
I have tested various scenarios. On my end, it appears that the Outlook application (both Outlook 365 desktop and Outlook 2019) is responsible for this .MSG to .EML conversion. The new ticket email notification from GLPI has the attachment file already in .EML format. Some of the testing:
When you download the EML attachment from the GLPI ticket and open it in Outlook, the HTML is partially broken, as previously reported. If you open the same EML file in another email client (such as Encryptomatic's viewer or Gmail web), the email and HTML display correctly.
When you send an email to GLPI with an MSG attachment from the Outlook Web App (OWA), it does not convert the MSG file to an EML. When you download the attachment from the GLPI ticket, it remains an MSG, and the HTML displays correctly.
Similarly, if you send an email to GLPI with an MSG attachment directly from the Gmail web app, there are no issues, and the MSG file remains an MSG. However, if you add the Gmail account to Outlook and send the email with an MSG attachment, Outlook converts the file to EML, resulting in the same issue.
It may be related to how GLPI handles attachments: From Outlook to Outlook, whether EML or MSG files, there are no issues. I tried sending an email with an MSG attachment from Outlook to another email address (not GLPI), and the file was converted to EML as expected. Downloading the EML attachment from the email in OWA, the HTML code for that EML file displays correctly. Issue is specific to downloading the attachment from GLPI.
Attached are three files for reference:
Some differences in the header: .MSG without issue:
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_001C_01DAD47C.93C86CF0".EML without issue:
Content-Type: multipart/alternative;
boundary="_000_001b01dad49e1ad949a0508bdce0gmailcom_".EML with issue:
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printableWould it have anything to do with the windows-1252 charset, if that's what Outlook is now using?
schieffahrer
commented
4 months ago I have found the problem with the display in Outlook. When converting to a MSG file, Unix line endings are typically used “\n”. Windows expects “\r\n” and therefore displays the file incorrectly. If I take the same EML file and convert the line endings, it is also displayed correctly in Outlook. msg_1_testmail.zip
The screenshot on the left shows the file from the GLPI, on the right the line endings have been changed on the same data. The left-hand display is incorrect and the embedded image is displayed as an attachment. The characters you see in the text are also partially incorrect.
schieffahrer
commented
4 months ago By the way, the error is exclusively in Microsoft Outlook. The problem does not exist in Thunderbird or other EML viewers and the display is correct.
github-actions[bot]
commented
2 months ago There has been no activity on this issue for some time and therefore it is considered stale and will be closed automatically in 10 days.
If this issue is related to a bug, please try to reproduce on latest release. If the problem persist, feel free to add a comment to revive this issue. If it is related to a new feature, please open a topic to discuss with community about this enhancement on suggestion website.
You may also consider taking a subscription to get professionnal support or contact GLPI editor team directly.
Code of Conduct
Is there an existing issue for this?
Version
10.0.15
Bug description
We sometimes receive MSG files from users sent to the ticket system by email.
If we create a ticket manually and add a MSG file, it is displayed identically. The situation is different with email imports. There are several problems here. The MSG file attachment is converted into an EML file. This is then unusable. For unknown reasons, the MSG is sometimes imported, but due to a change within the file, the display no longer works. German umlauts and special characters are displayed strangely. Is it possible to set GLPI so that MSG files are saved exactly as they are sent?
Examples are: "&nbs=;" or "Datenschutzb=stimmungen" (correct Datenschutzbestimmungen)
Relevant log output
No response
Page URL
No response
Steps To reproduce
Your GLPI setup information
Informationen über das System, die Installation und die Konfiguration
Server
Operating system: Linux webspace 5.10.0-30-amd64 #1 SMP Debian 5.10.218-1 (2024-06-01) x86_64 PHP 8.2.20 cgi-fcgi (Core, FFI, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, apcu, bcmath, bz2, calendar, cgi-fcgi, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, igbinary, imap, intl, json, ldap, libxml, mbstring, mcrypt, msgpack, mysqli, mysqlnd, openssl, pcntl, pcre, pdo_mysql, pdo_sqlite, posix, pspell, random, readline, redis, session, shmop, soap, sockets, sodium, sqlite3, standard, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, xsl, zip, zlib) Setup: max_execution_time="30" memory_limit="256M" post_max_size="512M" safe_mode="" session.save_handler="files" upload_max_filesize="512M" disable_functions="" Software: Apache () Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 Server Software: Debian 11 Server Version: 10.5.23-MariaDB-0+deb11u1 Server SQL Mode: NO_ENGINE_SUBSTITUTION Parameters: c1ticket@localhost/c1ticket Host info: Localhost via UNIX socket PHP version (8.2.20) is supported. Sessions configuration is OK. Allocated memory is sufficient. mysqli extension is installed. Following extensions are installed: dom, fileinfo, filter, libxml, json, simplexml, xmlreader, xmlwriter. curl extension is installed. gd extension is installed. intl extension is installed. zlib extension is installed. The constant SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES is present. Database engine version (10.5.23) is supported. No files from previous GLPI version detected. The log file has been created successfully. Write access to /var/www/clients/client1/web1/web/glpi/files/_cache has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files/_cron has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files/_dumps has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files/_graphs has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files/_lock has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files/_pictures has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files/_plugins has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files/_rss has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files/_sessions has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files/_tmp has been validated. Write access to /var/www/clients/client1/web1/web/glpi/files/_uploads has been validated. Web server root directory configuration seems safe. Sessions configuration is secured. OS and PHP are relying on 64 bits integers. exif extension is installed. ldap extension is installed. openssl extension is installed. Following extensions are installed: bz2, Phar, zip. Zend OPcache extension is installed. Following extensions are installed: ctype, iconv, mbstring, sodium. Write access to /var/www/clients/client1/web1/web/glpi/marketplace has been validated. Timezones seems loaded in database.GLPI constants
Libraries
LDAP directories
SQL replicas
Notifications
Plugins list
Anything else?
No response