@[deleted]As you can see from the attached screenshot (Screenshot 1), it worked just fine when I piped it to my instance of osTicket. The only thing I did was change the email addresses to point to mine instead of yours, removed some spaces on the blank new-lines, and voila it worked (Screenshot 2)!Maybe it's an issue with the way you're receiving it in your mailbox or something? Any errors via PHP error logs?Screenshot 1blankCheers.

Screen Shot 2018-05-29 at 11.12.01.png

Screen Shot 2018-05-29 at 11.20.02.png

@KevinTheJedi you are getting the same error, the body is just "(empty)" - there should be the actual text of the ticket instead. It's not a problem in the email I guess, but in the piping/encoding...?Also, congrats to me for forgetting to sanitize the base64 body text, wow

HI Guys, Any solution for this. I did update my php version from 5.6 to 7.0. and then i start getting this issue. I am using PIPE method for incoming.  

image.png

Oh yes, we upgraded to php7 recently as well, now that you mention it

4 months later

I have the same issues it just started happening I wish they would try and attempt to fix it. It may be worth mentioning what shared server you're using because I think it has something to do with specific installs on certain OS php versions

Hi,I upgrade my osticket from version 1.9.14 using the v5.6 from PHP to osticket v1.10.4 using now the v7.0 from PHP and I've the exat same issue. This is applied to new created tickets and also to when the end-users are replying to those tickets.I've tested by sending via iOS 12 and also via Outlook 2016. It was working great without any issue, befoe the upgrade.Any fix for this? It's very urgent!!Thanks.

Is these PHP Extensions installed?

mbstring

phar

intl

Yes, they're installed.See the image here: https://ibb.co/fH5r8e

Basically, it seems the variable "%{message}" responsable to show the email body sent from the end-users set on the templates on osticket, stop to work.However, the variable still the same on v1.10.4 comparing with the 1.9.14 like it's possible to see on that image: https://ibb.co/fjp4uKWhat could be done to fixe the issue?

Can you try editing the %{message} by deleting and save then re-add it and save it

@[deleted] it seems to me that you are talking about something completely different than what this thread appears to be about.This thread is about "body is only showing as (empty) when people email us from certain sources, so far iPhones connected through our Exchange and for emails sent from our Tine 2.0 calendar system."You appear to be talking about email template variables.  I think that you should probably start your own thread.  In it you should: - Describe the problem thoroughly, include steps to replicate the issue.  - Describe your system environment.- Provide an example email with full headers so a dev can use it to test.

Ok, so I found the issue. The isue with the v1.10.4 is caused now when the end-user have a HTML signature. When that happens, the content appear as {empty}.After some search, I fix the issue by comment the line 648 with the code: $input = preg_replace('/=({2})/ie', "chr(hexdec('\\1'))", $input); on  file: "mimeDecode.php" located on the directory: osticket/include/pear/Mail and I replace it with: $input = preg_replace_callback('/=({2})/i', function($m) { return chr(hexdec($m)); }, $input);After that, everything backs to normal and the email content and HTML signatures (if they exists) are present as well.I hope that OSTICKET will solve this on the next release!Thanks for everyone and I hope that solve the issue with other ones.

I've informed the devs of your post.  But if you are sure this is the right fix then you should make a PR to get it included in the next release.

5 months later

Did this get implemented? We recently upgraded to 1.10.5 and this problem (empty ticket body) appeared. Applied danielsantos' fix and it's working fine now.

I can't even tell you if the author of the post made a Pull Request at github with their code.

a month later

confirm that osticket 1.11 ini PHP72 still appear problem, but the solution danielsantos is worked.

thanks

18 days later

Hi there. I've update to the latest one 1.11 and using PHP 7.2 the issue still here, as before (when there's HTML signatures).

My workaround still working for some people here witch is great but on my case don't work.

I got my issue fixed with the comment here: https://forum.osticket.com/d/92969-subject-shows-content-empty/7

After I've downloaded the file "mimeDecode.php" from that website and place on the server, all the emails are received correctly on the ticketing system (visible through the Agent Panel and also through the emails the Agents receive).

I hope that helps OSTicket to fix this once for all, because from what I was able to search, it seems the issue still here since last year.

Was this ever resolved;

I am using IMAP to pull emails to create tickets and my tickets comes up with (empty) as part of the body and no attachment.

here is a copy of the message header:
Received: from xxxxxx (10.111.2.201) by
Sxxxxxxxxx (10.111.2.202) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id
15.1.1466.3 via Mailbox Transport; Wed, 17 Apr 2019 16:33:11 -0500
Received: from xxxxxxxxxxxxx (10.111.2.201) by
xxxxxxxxxxxxx (10.111.2.201) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id
15.1.1466.3; Wed, 17 Apr 2019 16:33:10 -0500
Received: from xxxxxxxxxxxx ([fe80::3562:e9cb:b4bf:5fc3]) by
SPWCIGEXC01.admin.gov.ky ([fe80::3562:e9cb:b4bf:5fc3%18]) with mapi id
15.01.1466.003; Wed, 17 Apr 2019 16:33:10 -0500
Content-Type: application/ms-tnef; name="winmail.dat"
Content-Transfer-Encoding: binary
From: "Garwood, Clayton" <xxxx>
To: CorisTickets <xxx>
Subject: FW: CORIS Setup
Thread-Topic: CORIS Setup
Thread-Index: AdTbXHRXurtiH0K9QsmrX1TZ5buN9QIwk4jwAV5QjUAAVhjbcAA9KXJgAMKcUsAALcLAMAA6SJEQAPJJMvAAQxMkQA==
Importance: high
X-Priority: 1
Date: Wed, 17 Apr 2019 16:33:10 -0500
Message-ID: <45bd4fe4fa6d477d88db15c75650efc4@xxxxx>
References: <80B7E3DF1D183944A353FDC920ACF5DD27C872F1@FCBDSAMBX02.WI.FCIB.com>
<80B7E3DF1D183944A353FDC920ACF5DD3A20A299@FCBDSAMBX02.WI.FCIB.com>
In-Reply-To: <80B7E3DF1D183944A353FDC920ACF5DD3A20A299@FCBDSAMBX02.WI.FCIB.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator: <45bd4fe4fa6d477d88db15c75650efc4@xxxxx>
MIME-Version: 1.0
X-MS-Exchange-Organization-MessageDirectionality: Originating
X-MS-Exchange-Organization-AuthSource:
X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthMechanism: 04
X-Originating-IP: [10.111.2.7]
X-MS-Exchange-Organization-Network-Message-Id: 48597762-9b2b-4ddc-88d3-08d6c37c49e5
Return-Path: xxxxxxxxxxx
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-EXCLAIMER-MD-CONFIG: 294acb16-5d1c-4f29-a949-025f674e1975
X-EXCLAIMER-MD-CONFIG: 25fce911-deb7-4e56-b8fd-69dd9087c441
X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.4428295
X-MS-Exchange-Processed-By-BccFoldering: 15.01.1466.003

Please assist

Write a Reply...