@BlackHawk17

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.

@KevinTheJedi

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. ?

@KevinTheJedi

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

@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.

@KevinTheJedi

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. ?

@BlackHawk17

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.

Note

Get this, I just tested mail from native iPhone app via piping on v1.11 and this worked without a hitch.

Cheers.

@KevinTheJedi

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

@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.

@KevinTheJedi

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

@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...)

23 days later

ryance85

Hello ryance85

Tried that and disable html format worked for a while then gone back to acting up again.

Any other suggestions

Regards

3 years later

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

Write a Reply...