PHP 8.1/8.2 - "Check Inbound Mailbox" Job fails on Email Accounts that use Basic Auth #4960

New issue

Open

opened 2026-02-20 16:26:55 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-20 16:26:55 -05:00

Owner

Originally created by @johnM2401 on GitHub (Feb 17, 2023).

Issue

When the "Check Inbound Mailboxes" job runs, it appears as though Inbound Accounts that use Basic Auth are experiencing issues.

Using either PHP8.1 or PHP8.2, Running:
php -f cron.php

Does not read Basic Auth accounts, returning:
"Could not get an IMAP connection resource for ID [mailbox ID]"

(Both IDs in this screenshot are Basic Auth Mailboxes)

I also have one more mailbox that uses Oauth2, but this appears to import as expected.

Expected Behavior

Inbound Mail Accounts should be importable, even when Basic Auth.

Actual Behavior

Mail Accounts that use Basic Auth are not Imported, and instead skipped.

Possible Fix

Steps to Reproduce

Create two Inbound Mail Accounts, one using Basic Auth, One using Oauth2
In PHP 8.1 or 8.2, run php -f cron.php to fire the "Check Inbound Mailboxes" job
See that the Basic Mail Account does not get imported
See that the OAuth2 Account does get imported.

Your Environment

SuiteCRM Version used: 7.13.1
Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): Firefox 109.1
Environment name and version (e.g. MySQL, PHP 7): PHP8.1 / PHP8.2
Operating System and version (e.g Ubuntu 16.04): Ubuntu 18.04

Originally created by @johnM2401 on GitHub (Feb 17, 2023).     #### Issue When the "Check Inbound Mailboxes" job runs, it appears as though Inbound Accounts that use Basic Auth are experiencing issues. Using either PHP8.1 or PHP8.2, Running: ```php -f cron.php``` ![image](https://user-images.githubusercontent.com/13675281/219651440-968c64f3-42f6-455b-bbc3-b400a4fc4d68.png) Does not read Basic Auth accounts, returning: "Could not get an IMAP connection resource for ID [mailbox ID]" ![image](https://user-images.githubusercontent.com/13675281/219651513-b3f9e1cb-f9d7-4035-813d-52b8447de502.png) (Both IDs in this screenshot are Basic Auth Mailboxes) <br> I also have one more mailbox that uses Oauth2, but this appears to import as expected. <br> #### Expected Behavior Inbound Mail Accounts should be importable, even when Basic Auth. <br> #### Actual Behavior Mail Accounts that use Basic Auth are not Imported, and instead skipped. <br> #### Possible Fix #### Steps to Reproduce   1. Create two Inbound Mail Accounts, one using Basic Auth, One using Oauth2 2. In PHP 8.1 or 8.2, run ```php -f cron.php``` to fire the "Check Inbound Mailboxes" job 3. See that the Basic Mail Account does not get imported 4. See that the OAuth2 Account *does* get imported. #### Your Environment  * SuiteCRM Version used: 7.13.1 * Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): Firefox 109.1 * Environment name and version (e.g. MySQL, PHP 7): PHP8.1 / PHP8.2 * Operating System and version (e.g Ubuntu 16.04): Ubuntu 18.04

deekerman added the

Type: Bug

Priority:Important

Area: Emails

Status: Team Investigating

Area: PHP8

labels

2026-02-20 16:26:55 -05:00

deekerman commented

2026-02-20 16:26:56 -05:00

Author

Owner

@SuiteBot commented on GitHub (Feb 17, 2023):

This issue has been mentioned on SuiteCRM. There might be relevant details there:

https://community.suitecrm.com/t/enable-smtp-over-ssl-or-tls-not-saving-setting/87920/8

@SuiteBot commented on GitHub (Feb 17, 2023): This issue has been mentioned on **SuiteCRM**. There might be relevant details there: https://community.suitecrm.com/t/enable-smtp-over-ssl-or-tls-not-saving-setting/87920/8

deekerman commented

2026-02-20 16:26:57 -05:00

Author

Owner

@gunnicom commented on GitHub (Aug 30, 2023):

Same problem for me after update from 7.12.12 to 7.14
Edit:
For me it was a combination of update and mismatch in DNS name to the certificate on our Exchange server. It seems it is stricter now with that mismatch than before.

@gunnicom commented on GitHub (Aug 30, 2023): Same problem for me after update from 7.12.12 to 7.14 Edit: For me it was a combination of update and mismatch in DNS name to the certificate on our Exchange server. It seems it is stricter now with that mismatch than before.