Email Fetching via "Cron Job" Error: IMAP Authentication cancelled

fzs122

I recently migrated a fully functioning installation of the (most recent version available(and unaltered)) Synology Package of osTicket to a new Synology (identical model and DSM version). Everything is working fine except the Email Fetching via IMAP+SSL "Cron Job." I am using the identical User-defined script that worked perfectly on the previous Synology host: /usr/local/bin/php56 /volume1/web/osticket/upload/api/cron.php
"Fetch on auto-cron" works fine, but I can't always ensure that someone will be logged in to facilitate that function.

osTicket Version: 1.10.1 (yes, I know it is ancient, but it is the last version posted by Synology and I know the Cron Job has the ability to work in this overall configuration). I have tested upgrading, but it didn't resolve the issue, so I reverted to a known-capable set of variables for now.
Web Server Software: Apache 2.2.34
MySQL Version: 10.3.21
PHP Version: 5.6.40
PHP Extensions: All installed and enabled

I find very little in the various associated logs. Perhaps the best indication is an email that I get when the process fails:
Subject: Mail Fetch Failure Alert
Body: osTicket is having trouble fetching emails from the following mail account:

User: support@mydomain.com
Host: my email host
Error: IMAP Authentication cancelled

5 consecutive errors. Maximum of 5 allowed

This could be connection issues related to the mail server. Next delayed login attempt in aprox. 10 minutes

https://support.mydomain.com/osticket/upload

I have verified using multiple techniques that my email host is serving up IMAP+SSL via port 993 without any issue. I even put an IMAP client on another host in the same subnet that the Synology is on to verify IMAP service, IMAP account, and IMAP password are working and correct. (It has to be working and correct since "Fetch on auto-cron" works, right?) I've installed additional tools on the Synology so I could use telnet. The telnet session from the Synology to the email host via port 993 results in a positive connection.

There is nothing recent in /var/log/php56-fpm.log
Mail Sending is working fine, as I'm getting the emailed alerts that the Cron Job is failing and customers are getting their notifications.
There is nothing recent in /var/log/httpd/apache22-error_log
There is nothing recent in /var/log/nginx/error.log

I do find the following in /var/log/messages (but I don't know if it is related to this or maybe it has something to do with my https session with the Synology UI). "LAS_Rackstation" is the hostname for the Synology.
2020-04-12T14:20:05-04:00 LAS_RackStation notification_refresh_token: cred_request.cpp:979 (pid=25826)HTTP Error(400)
2020-04-12T14:20:05-04:00 LAS_RackStation notification_refresh_token: notification_refresh_token.cpp:57 Failed to process curl process, errorno: 14
2020-04-12T14:20:05-04:00 LAS_RackStation notification_refresh_token: notification_refresh_token.cpp:134 SYNOSmtpRefreshToken failed.
2020-04-12T14:25:05-04:00 LAS_RackStation notification_refresh_token: cred_request.cpp:979 (pid=26209)HTTP Error(400)
2020-04-12T14:25:05-04:00 LAS_RackStation notification_refresh_token: notification_refresh_token.cpp:57 Failed to process curl process, errorno: 14
2020-04-12T14:25:05-04:00 LAS_RackStation notification_refresh_token: notification_refresh_token.cpp:134 SYNOSmtpRefreshToken failed.

I've increased osTicket Log Level to "All." This shows a periodic "Mail Fetch Failure Alert" with wording that matches the email I'm getting. I also see "Cron Job" entries that match the scheduled time of the script. The content is only:
Cron Job
Cron job executed []

I used WinSCP to verify that nothing unexpected shows in file permissions.
I verified that the /usr/local/bin/php56 and the /volume1/web/osticket/upload/api/cron.php paths are valid.

If I run the script via the Synology UI, specifying for it to show me the result, I get:

I'm stumped, but I'm hopeful because I've been very lucky in the past with folks in this forum solving obscure issues. Here is my Hail Mary.

ntozier

My first suggestion is that you re-enter the password on the email configuration page. (Not that I think it will actually do anything, but please humor me here.)

My understanding is that Synology altered the distribution of osTicket to make it work in their platform. I have no idea what they did, but you might want to contact Synology support to ask. While you are at it you might want to let them know that 1.10.x reached end of support some time ago.

Is there some log that you can look at on the mailserver side to see the (failed) connection attempts that might shed some additional light on why this isn't working?

I'll ask the devs to take a look at this thread to see if they have any additional ideas.

fzs122

I've tested changing the password, eliminating all but alpha-numeric characters in case the cron job is failing to pass something more complex (or doesn't like the position of one or more complex characters). Unfortunately, I'm getting the same result. I don't remember if it recorded the IP Address when "Cron Job" was working on the previous host. Here is a snapshot of the details of the "Cron Job" failure also showing earlier successful "Auto Cron" events when I was logged in with that setting enabled.

I agree that Synology did something to make osTicket work as a package on their platform. I found out (the hard way) when I tried to do an in-place upgrade (that failed) from one Synology-provided version of osTicket to the version I'm on now. Synology Support disavowed any manipulation of the osTicket code (but the excellent folks on this forum PROVED Synology Support was wrong about that). I'd love to move forward with a newer version, but I'm stuck not knowing exactly what tweaks were made where and I've only managed to get "500 internal server" errors after installing the latest code (a problem for another day). I'd love it if Synology either sponsored a current package or someone in the community would post it as a third party app. I use Plex on my home Synology and Plex fully supports upgrades in place using the "Manual Install" option. The app just detects that it isn't the latest version and prompts you to download and install (or ignore) an .spk file. Dead simple upgrades, but I digress.

I, too, wondered if there were any sort of logging or debug setting I could put on my email host. I haven't found anything at all. From the mention of "IMAP Authentication cancelled" and possible "connection issues" mentioned in the osTicket failure notification, I suspect it really isn't even getting as far as successfully connecting to the email host. I do see an (understandable) SSL/TLS error on the email host's console when I telnet to port 993 from the Synology to the email host and have nothing to move the session forward after the initial connection. All this has me wondering about at least three things:

Is there any log or logging on the osTicket side (or underlying linux/packages on the Synology) that I'm failing to enable and/or review?
Is there something wonky with the Synology routing of the "Cron Job" that is causing it to fail before it can initiate the connection with the email host? I must admit that, while the host and osTicket version are the same, this network is ever so slightly different and that might be making all the difference. I initially had to ask Synology Support for help ensuring that osTicket would respond on the correct network as the Synology is wired both for the LAN and DMZ. It "automagically" resolved itself after some pounding on the cryptic network options (the Synology's choice of what network/gateway chosen for the NAT'd osTicket internet users).
Finally, and probably most importantly, is there any further explanation of the difference between how "Cron Job" works vs. how "Auto Cron" works? I'd love it if I could trace the steps in some log somewhere because this feels like it would be the simplest method for troubleshooting the issue. It baffles me that "Auto Cron" works flawlessly and (as far as I know) a scheduled Cron Job the runs without errors (but also without the desired result) is just supposed to emulate that function without the requirement of a user being logged in.

KevinTheJedi

@fzs122

Is there any log or logging on the osTicket side (or underlying linux/packages on the Synology) that I'm failing to enable and/or review?

The related errors are most often in:

Apache Error logs
PHP Error logs
Browser Console logs
Server logs (like journalctl and/or /var/log/)
osTicket System Logs
Mailserver connection and error logs

Being that it's a Synology setup I assume they restrict you to something like CPanel (like most shared hosts) which makes the debugging process more difficult than usual. If you have SSH access (which I hope you do) I'd suggest tailing the log files directly instead of looking at CPanel error logs, etc.

Is there something wonky with the Synology routing of the "Cron Job" that is causing it to fail before it can initiate the connection with the email host?

There could be something wonky but you'd most likely see it in your server logs, php logs, and/or mailserver logs.

Finally, and probably most importantly, is there any further explanation of the difference between how "Cron Job" works vs. how "Auto Cron" works?

Auto-Cron is called every so often when an Agent is logged in. An Agent HAS to be logged in in order for Auto-Cron to run. Cron Jobs work by calling a script via command line automatically on a set time-frame (eg. every minute of every day for indefinitely).