Email Fetching via osTicket is intermittant

TAS

Email Fetching is not pulling email responses when logged in as Administrator.
Auto Cron is showing as firing in the System Logs.
Responses to tickets are not being appended to ticket.

System Log shows Auto Cron fired twice and then stopped after I logged in.

I have checked

PHP error logs

Zend is unhappy. Enabled php_opcache in the .ini as suggested by multiple posts. No change but system seems to be working.

Example [04-Feb-2026 16:32:15 UTC] PHP Warning:  PHP Startup: Invalid library (appears to be a Zend Extension, try loading using zend_extension=php_opcache.dll from php.ini) in Unknown on line 0

Server Logs
Have found nothing of note.

1801	Error	Microsoft-Windows-TPM-WMI
100	Warning	MySQL	Application
9009	Warning	Microsoft-Windows-IIS-APPHOSTSVC - unhappy at not being able to delete a directory

[PHP Modules]
apcu
bcmath
bz2
calendar
Core
ctype
curl
date
dom
fileinfo
filter
gd
gettext
hash
iconv
imap
intl
json
ldap
libxml
mbstring
mysqli
mysqlnd
odbc
openssl
pcre
PDO
Phar
random
readline
Reflection
session
SimpleXML
soap
SPL
standard
tidy
tokenizer
xml
xmlreader
xmlwriter
Zend OPcache
zend_test
zip
zlib

[Zend Modules]
Zend OPcache

What am I missing?

KevinTheJedi

TAS

You need to constantly be doing activity. I would never rely on auto-cron... why not simply create a cron job/scheduled task?

https://docs.osticket.com/en/latest/Getting%20Started/POP3-IMAP%20Settings.html

Cheers.

TAS

Well, osTicket Email Fetching was working up until a few weeks ago...
Then, it stopped working consistently.

I thought it was a virtual server reconfiguration that was forced on me.
I spent much of my time searching for a server side problem that would cause this.
I am still not sure that it is NOT a server side issue.

I put in a ticket and you rightfully pointed out that I needed to update some things.
I did and initial indications were that the problem was solved.
But... not. Sigh.

Now, as I've been sitting here, I have osTicket open in another window and have sent a number of responses to a ticket I created.
Email Fetching has not fired.
I can see my response in the the email folder in the Outlook email box.
I can also see 4 other responses that have not been picked up and appended to existing tickets.

I can do a scheduled task. I've been avoiding this because it is one more thing to set up.
Also, I'm not really sure it will work. My skills are rusty at the moment.
I tried a manual firing of a cron job and nothing happened. Nothing updated.
I suspect I parsed the line wrong in the CMD window but so it goes.

Thoughts?

TAS

More info
Manually fired cron to no effect.
None of the associated tickets were updated.

Auto Cron email fetcher also fired.
I need to turn that off.

I'm still thinking its something on server side...
Where should I look?

The next thing is to nuke osTicket from orbit and redo the whole system.
Don't really have time but it has to work and be trust worthy like it was.

KevinTheJedi

TAS

So can you confirm:

Email fetching is enabled globally
Email fetching is properly configured and enabled for at least one system email
You can successfully save changes on the email configuration screen when the Remote Mailbox Status is set to Enable

Check the email_account table in the db and see if it has last activity or if it has an error.

Cheers.

TAS

Email fetching is enabled globally -> Yes
Email fetching is properly configured and enabled for at least one system email ->
You can successfully save changes on the email configuration screen when the Remote Mailbox Status is set to Enabled. -> Yes
Check the email_account table in the db and see if it has last activity or if it has an error. - > Checked - No errors. Can see last cron cycle time in db

I'm going to delete the email address and remake it.
Thoughts?

TAS

In the System Logs the manual CRON job shows but doesn't have an IP address like the Auto Cron.
Is that normal?

KevinTheJedi

TAS

Yea it’s ran locally not from web so no IP unless you do remote cron via web. I mean if you see last activity with no errors that means it logged in and polled the mailbox successfully. Can you show your remote mailbox settings?

Cheers.

TAS

Updated Oath2 with new Token
Fired Cron manually.
Nothing updated.

TAS

KevinTheJedi

TAS

Well for one you set to Do Nothing... don't do that (not recommended). Instead, set to Archive - Move to Folder and set an archive directory. Note, you don't have to create the folder beforehand because IMAP should allow for it to be created automatically.

!!! BEFORE YOU DO THAT !!!
Make SURE you move ALL already processed mail out of the INBOX before making this change. If not, the system will go through and reprocess every single email in the inbox dating all the way back to the start. So make absolutely sure all already processed mail is out of the inbox before changing the Fetched Emails setting.

Cheers.

TAS

Ok. In process.
(Always had it set to do nothing and never had a problem. )
🙂

KevinTheJedi

TAS

That will just eventually cause issues though especially if there is ever a bug that triggers reprocessing from beginning instead of from the top minus emails per fetch -OR- if there is ever stuck mail. Some mail may never be processed because it's passed the threshold of how many emails per fetch and since processed mail isn't removed from the inbox each time it will never catch up and process said mail. That's why we say "not recommended" as it's good for testing but not long-term production use.

Although, you are technically correct in that this technically shouldn't cause fetching issues in the sense of mail not being fetched at all with no errors being logged; but you never know.

Cheers.

TAS

As you say, it was a mailbox problem.
Once I cleared out the Inbox, AutoCron started firing properly.
I also found a malformed email on the server that shouldn't have been there...
Between the two items I'm going to tentatively say the problem is solved.

We have a rather large mail server storage allotment. I've been keeping tickets since 2014 and I saw no reason to delete anything. Also, I had the ability to down 100-200 emails at a time ( not that that ever happened in this environment.
for me, osTicket has been stable the entire time with no errors or happenings.

Summary

Tested email system using email Diagnostic and determined that the SMTP sending was operating
Checked OAuth2 operations. Checked to make sure token was fresh and set.
Checked to make sure OAuth2 Secret has not expired. My Secrets expiration date was set by IT. I now know when it expires and can request a new one when it does.
Once I verified proper operation all that was left was the mailbox.

So....

Cleaned and inspected emails in the Inbox.
Cleaned out the mailbox and sent the received emails to Archive once processed.
Will perform operations check tomorrow to see if things are still working.

Thank you Kevin

KevinTheJedi

TAS

Nice! Glad you got it all working again!

Cheers.