- Edited
I doubt it but due to the circumstances, try installing and enabling APCu and see. I do have this enabled on mine so maybe?
Cheers.
I doubt it but due to the circumstances, try installing and enabling APCu and see. I do have this enabled on mine so maybe?
Cheers.
Ok, I successfully installed APCu and the exception no longer shows in the System Info page.
Unfortunately this did not solve the issue. So then I decided to back everything up and upgrade to v1.11 but this did not solve the issue and now the issue seems even worse. ?
Also tried the @danielsantos fix on file /include/pear/Mail/mimeDecode.php line 648 with the code: $input = preg_replace('/=({2})/ie', "chr(hexdec('\1'))", $input); and replacing it with: $input = preg_replace_callback('/=({2})/i', function($m) { return chr(hexdec($m)); }, $input); but that didn't help either. Oh boy ?
Also looked into the threads you sent me yesterday but tried a few things that didn't work then I fell asleep. LOL
Today I noticed that now I'm actually capturing some email errors in the system log.
API Unexpected Data - system_emails: Unexpected data received in API request
The warning errors are from the testing I did last night but I didn't see them until today and I've already deleted the test tickets.
I'm guessing the update to APCu might be allowing the system log to capture the errors now.
I'm actually going to clear the errors and see if I can see exactly when it happens with one test ticket.
I will be reporting back later right now I have to help some more customers. ?
So you made the changes listed in both of these pull requests?
https://github.com/osTicket/osTicket/pull/4731
https://github.com/osTicket/osTicket/pull/4758
Cheers.
Pull 4731 - 1 file change = include/class.ticket.php
Downloaded RAW file and changed extension from txt to php then uploaded to the correct path and changed permissions.
Pull 4758 - 1 file change = include/ajax.forms.php
Downloaded RAW file and changed extension from txt to php then uploaded to the correct path and changed permissions.
First test just using fake gmail account as customer created ticket online then replied to ticket email using Outlook on desktop and received (empty) again....now every email sent from anywhere is giving (empty)
Outlook
IPhone
Shopify App Support Form
Here are the errors in dashboard system logs:
API Unexpected Data
thread_entry_recipients: Unexpected data received in API request
API Unexpected Data
system_emails: Unexpected data received in API request
version 1.10.5 seemed to be doing a little bit better but did not like iPhone or Shopify emails
version 1.11 no email replies are working now from any platform as far as I can tell.
Note: I'm using namecheap hosting.
Again the emails are arriving on my Web Mail Server and Outlook 2013 and Mozilla Thunderbird just fine and completely intact but are getting stripped out inside osTicket and show up as (empty) with errors now.
Please advise...Regards, BlackHawk17
At this point I'm at a loss as it works just fine for me on 1.10.5 and 1.11.
Have you tried sending mail from the Gmail app instead?
Cheers.
Surprisingly the Gmail app worked just fine but that will take care of 1% of my customers. LOL
I can't believe how much time I've spent on trying to make this work....now I'm cutting and pasting from Outlook to my Help Desk all day long. This is not supposed to work like this. damn it.
Outlook?
We use Outlook 2016 here, and do not have the problem that you are experiencing.
You had mentioned "Shopify App" so I presumed that the app was malforming the emails.
Replying to ticket via Gmail App - Works great everytime
Replying to ticket via Gmail on Desktop Web Page - Fails everytime.
Web Based Gmail produces these errors in osTicket System Logs:
API Unexpected Data - thread_entry_recipients: Unexpected data received in API request
API Unexpected Data - system_emails: Unexpected data received in API request
Thank you guys for trying to help me. ?
This is driving me nuts too. Something has to be awry with your setup as emails from Gmail desktop/mobile work just fine for me on the 1.10 series and the 1.11 series (even old 1.9 series). Even YaHoo emails work fine in my testing. Piping works as well as fetching and we have thousands of customers using outlook, gmail, yahoo, and other 3rd party mail providers just fine on the latest codebase (v1.11) on a daily basis. Before this we were running v1.10.x and there were little to no issues with this either for years. Very little issues have been reported with incoming mail and 9 times out of 10 it was the mail provider/mail server/configurations causing the issues. The other 1 out of 10 reports were actual issues and have all been addressed and included in the maintenance releases of v1.10.1-5. If you’re running 1.10.5 or v1.11 you should see no issues with your incoming mail.
A good way to test stuff like this is to get the entire raw contents of an email that hasn’t been fetched yet (in gmail you can click on an email, click the more button, and select view original), copy the raw contents, make a .txt file, paste the contents in the .txt file, save it, and run the following command (will differ depending on the system you’re running; just google how to run a php script via cli on your system; the api/pipe.php < filename.txt
part should be the same though):
$ php /path/to/api/pipe.php < filename.txt
This will attempt to pipe the email into the system and if successful should create a ticket, send out an alert, etc. (this simulates email piping) If not, you should see errors. With the errors start looking at what it’s complaining about and check the corresponding data in the raw email to see if anything is malformed/etc. like recipients/etc. You can post the errors you find here if you need more help.
Get this, I just tested mail from native iPhone app via piping on v1.11 and this worked without a hitch.
Cheers.
Thanks for your last reply!
However here is what I ended up doing today 3/21/19
Blew out my TEST Help Desk and Rebuilt it with a clean install of osTicket ver1.11
Still found the Forwarding/Piping method to be unreliable and stripping out the body of the messages and generating the API errors most of the time unless I was replying specifically from the Gmail App on my iPhone.
So I turned off the forwarding/piping method and turned on the Fetch/IMPAP/SMTP/CRON JOB method.
And so far its working correctly with Native iPhone Mail, iPhone Gmail App, Gmail Web and Outlook 2013 from my desktop pc.
Cron Job Command:
osTicket Example = */5 **** nobody /path/to/php /path/to/api/cron.php
The one I used = */5 **** /usr/bin/php /path/api/cron.php
Note: I had to remove the (nobody) as it caused the job to fail when using it
I just changed over to IMAP/Cron on my live Help Desk and it looks good so far. ?
Customer New Ticket Using Web Form = Good
Customer New Ticket from Shopify Web Form = Good
Reply from Outlook 2013 on Desktop pc = Good
Reply from Web Base Gmail on Desktop pc = Good
Reply from iPhone using Gmail App = Good
Reply from iPhone Native Mail App = Good
Now this is how it's supposed to work...why didn't I do this sooner. LOL
Also I have a Ticket with NameCheap Support asking them to explain why the forwarding/piping is generating the API errors.
Well see what happens but at least this IMAP/Cron Job method might work for now. ?
Thanks again for all your help and support!
Regards, BlackHawk17
WHEW! Sweeeettt! I'm so glad it's working for you now. The piping issue is driving me insane because I can't replicate it! I wish I could so I could at least explain to you why but I can't ?
Cheers.
Yes, everything seems to be working fine when not using piping.
Here is what the boys and girls at namecheap had to say after testing my TEST osTicket Help Desk around 4:00am this morning:
Hello BlackHawk17,
Thank you for providing the requested details!
Our technicians have checked the case on their side. According to their check, this issue is related to the software and our Senior technicians will not be able to support it. We recommend investigating this issue with the osTicket developers, since they are aware of the software's architecture.
Since this is not the first time when users faced the issue with osTicket software, they should investigate and resolve it.
Feel free to get back to us if their Support Team ask you to check any specific settings on the server.
Do not hesitate to contact us if you have any additional questions or concerns!
....................Oh well it looks like this namecheap piping issue with osTicket will not get fixed for a very long time.
In the meantime I'm happy to have a working solution..... ?
Thanks again....Regards, BlackHawk17
It's funny because they are the only ones having this issue ? GREAT!
I'm glad you have a working solution as well. Just bugs me that I can't figure it out as I don't have access to the servers/etc. Unfortunately, I would need an account with them to configure, test, debug, etc.
Cheers.
FYI, I have just upgraded our 10.4 system to 11.0 and I also get the
"API Unexpected Data
thread_entry_recipients: Unexpected data received in API request" warning, although I believe I'm getting all the mails...
Having said that, I'm NOT getting the
"API Unexpected Data
system_emails: Unexpected data received in API request"
NOR I have the empty emails issue mentioned by @BlackHawk17 (tried Android Gmail APP/desktop edition)
I'm using the piping method and I'm quite reluctant to move to the IMAP/cron method...
I have applied the #4788, #4731 and #4758 pull requests, but not (yet) the mimeDecode patch from danielsantos.
PHP 5.6.40/all required PHP extentions installed/Ubuntu 14.04.6 (...yes I know...)
https://forum.osticket.com/d/92969-subject-shows-content-empty/5
The reason is because pear mime code has a difficult time interpreting HTML characters and separating them so it displays as empty.
Hello ryance85
Tried that and disable html format worked for a while then gone back to acting up again.
Any other suggestions
Regards
I got the same issue with (empty) message body after the upgrade to v1.17.
After looking into the mimeDecode.php code and analyzing the email source, I figured out the problem and found a fix.
Email message had 'Content-Type: multipart/multipart' which was not processed in the decode function.
so I added this code after line 310:
case 'multipart/multipart':
if(!isset($content_type['other']['boundary'])){
$this->error = 'No boundary found for ' . $content_type['value'] . ' part';
return false;
}
$default_ctype = (strtolower($content_type['value']) === 'multipart/digest') ? 'message/rfc822' : 'text/plain';
$parts = $this->boundarySplit($body, $content_type['other']['boundary']);
while (count($parts)) {
$part = array_shift($parts);
list($part_header, $part_body) = $this->splitBodyHeader($part);
$part = $this->decode($part_header, $part_body, $default_ctype);
if($part === false)
$part = $this->raiseError($this->error);
$return->parts[] = $part;
}
break;
Hope it helps.
Cheers