Prior to osTicket `v1.17.x` email fetching required and used php-imap module to
decode and parse emails, whereas locally or remotely piped emails (via API
endpoint) used a Raw Email Parser ("Mail Parser").
Using two separate backends meant duplicated code, logic and inconsistent email
processing.
Starting with osTicket `v1.17.0`, we overhauled the Email Backend to OAuth2
support and in the process we switched toxusing a unified Mail Parser for both
fetched and piped emails. To determined how the email got delivered in order to
handle errors for the interfaces accodingly, we relied on `PHP_SAP`I /
`php_sapi_name()`.
That was shortsighted because of the value of `PHP_SAPI` can be different in
the following cases;
1. Email Fetching can be triggered by autocron (Staff Activity) or by a remote
task (API)
2. `PHP_SAPI` cannot be relied on for php installations using php-fpm, php-cgi
or custom binaries for php CLI executable
3. Cron Job / Task entry "user-name" or "command path" might use separate php
executables (related to `#2`)
4. Triggering cron/php via php-fpm socket connection e.g using FastCGI Client
Since emails are fetched in batches - Email Fetching, unlike stateless API
requests, should be considered a CLI operation regardless of how it gets
trigerred, this necessary so the system can gracefully handle fetch and parse
errors.
This commit does just that and a few other minor logic / code cleanup.
~ Peter - with love!
d4d9c4242f