Excessive errors processing emails

bernarddt

Good day,

Server Information
osTicket Version v1.18 (724de45) — Up to date
Web Server Software LiteSpeed
MySQL Version 10.5.21
PHP Version 8.1.20

We have a instance of osTicket begin hosted on cPanel/Linux. It works fine, otherwise, but we get a lot of email processing errors. This only happens when specific clients email us. So not all email gets the error. Normally when this happen, I have to log onto webmail, then "forward" the error email to the same email account. This always fixes the problem. So when the webmail (HorderMail) processes the email, it seems to remove any problem characters.

We used to use an much older version of osTicket and never had problems with these client email, but ever since upgrading we have been getting these errors.

Would it be possible to provide the original .eml file that is causing the problem, and seeing if you can understand what is causing the processing error?

The logs only show "Excessive errors processing emails for plain://mail.tickets.btx.co.za:110/POP (BTX Support ). Please manually check the Fetch Folder () [1/30 - 0/1]".

So if it is possible I can get more detailed logs, if there are instructions of enabling it? Note that we use a cron job to processes the email, but I don't think this is much of a problem, since the same email work fine when just forwarded to using the webmail.

KevinTheJedi

bernarddt

Set you Log Level to DEBUG and it should catch and log the error. If not you can go here and add error_log($t->getMessage());:

https://github.com/osTicket/osTicket/blob/8f6c2ec794c0026e55bf7e862c1953c7f4fa2f99/include/class.mailfetch.php#L155

Cheers.

bernarddt

Thanks @KevinTheJedi,

I've set the debug level to "DEBUG", and now I've got a new response that looks like this:

Mail Fetcher
Invalid header value detected

Unfortunately, nothing more to indicate which header value this is.

Any further advice?
Should I log a bug report for this?

KevinTheJedi

bernarddt

You will need to move the affected mail out of the inbox and see if others fetch. If so it’s likely just a malformed email.

Cheers.

bernarddt

KevinTheJedi , the issue is, I didn't get this error on an older version of osTicket, but ever since using a new installation, these errors pop up regularly. So I've had them from email sent from MS Exchange, but also Google Workspace.

And effectively I would want osTicket to "handle" the error by not failing but rather ignoring it or being able to read it correctly.

At this point I'm constantly sitting with the inbox open and moving these mails out of the inbox. And once it gets to this error it spams me with error emails every one minute (my fetch rate is on a 1min cron job).

I was hoping by providing the email it can be tested and determined why osTicket would fail on these mails, and by solving this "issue" it would work better for everyone.

KevinTheJedi

bernarddt

Post an example here.

Cheers.

bernarddt

Hi Kevin,

I've uploaded one of the complete emails here:
https://transfer[dot]pcloud[dot]com/download.html?code=5ZO2DNVZy29pVWDQVEfZtTuUZ69adzF9Nk4hmHdN2BKSJK8sikTkk

Bernard

KevinTheJedi

bernarddt

I don't go to 3rd party sites, please upload it directly to the Forum.

Cheers.

bernarddt

The forum does not allow .eml files? It says the file is not supported.

bernarddt

email-sample.7z

52kB

Ok looks like I can upload a 7z file.

KevinTheJedi

bernarddt

My bet would be the X-Ham-Report header as that looks crazy (haven't seen that before; ever) but I'll have to do some testing on Monday to see. If you want to test you can try piping that mail to see if it works (eg. php /path/to/osTicket/api/pipe.php < email_file.eml). If that fails try to fully remove the X-Ham-Report header (and it's contents) and retest. If that works then the issue is definitely with that header. If that header is the problem then we will try to see if there is anything we can do. I will say that we use an older library (PEAR) to parse the headers, address list, etc. so it could be due to this package not reading the X-Ham-Report header correctly. Unfortunately, this package no longer receives updates and we aren't switching any libraries for current (legacy) codebase as we are focusing on v2.0 development. But it is strange as the PEAR packages should be the same version in 1.16.x as in 1.17.x|1.18.x so not sure why that has any affect. We do use a different library to fetch the emails so maybe that's contributing a little. Anyways, I'm just guessing at this point until I can do further testing next week some time.

With v2.0 we will have fully modern libraries and such that should process modern mail headers much better. So please stay tuned!

Cheers.

bernarddt

KevinTheJedi
Ok so to help you out here, our previous version of osTicket was:

osTicket (v1.10)

So really old, but that one didn't fail on headers. Come to think about it, we also used a different email server, and since headers are added by the email server, there is a very big chance that it is the source.

I'm looking forward to v2.0 for sure!