Dear pstevens, my main thing is that I have installed SuiteCRM 8.6 and I canât get the inbound email to work. This is by the way the same in 7.14, therefore I now chose to do a fresh 7.11 installation where now everything works.
I noticed that if you put the php version back to 7.4 that the âSelect Inboxâ popup appears, but the folder list is empty. All permissions are as wide open as they can.
I must have read practically every post on this topic, even tried to simplify the code and put echoâs to the error-log to check that I had the right login credentials, but nothing works. So if you have a clear workaround for this, I would appreciate a step-by-step guide, and many others with me I think.
We actually having exact that problem, that the authentication fails for sending mails (SMTP) - from the logs i would say itâs cause the Authentication isnât correct.
I already tried to research but i cant find the configuration file where i have to set $mail->AuthType = 'CRAM-MD5';. Can anyone tell me where to set this configuration?
I already researched the code and from my understanding, when nothing else is set, it should automatically try all the authentication methods, including CRAM-MD5 as the first one.
The SMTP configuration is correct and works fine within other software/tools.
Well I can confirm there IS an issue and Im not entirely sure its a SuiteCRM issue.
I have been using the email in various forms of Suite for a while, however on a brand new Suite8.8 I was setting up a bounce account connected to an IMAP server and encountered the Auth/SASL issue.
This was on a shared server with no auth_sasl installed, I have downloaded in and then in config_override included the SASL.php file. Great you think this should fix it. However it doesnt, Suite is now using the javanile imap2 library to perform IMAP connections, I believe there is a bug in there.
in vendor/javanile/php-imap2/src/Roundcube/ImapClient.php near the top there is this:
use Javanile\Imap2\Auth_SASL;
further down there is a :
new Auth_SASL;
this errors with a âunable to find \Javanile\Imap2\Auth_SASLâ
Changing âuse Javanile\Imap2\Auth_SASL;â to âuse \Auth_SASL;â
Fixes it (as long as you are including the SASL.php file)
I am assuming that the inconsistent nature of this is because the negotiation with the IMAP server includes determining the best connection strategy, and if it doesnt need the AUTH_SASL then it doesnt trigger.
From a Suite Perspective, Auth_SASL is available as a composer require option and I would think it would make sense to include it that way as a default to ensure its not needed at the server level.
I have tried running a composer require pear/Auth_SASL at the root level instead of the include in config_override.php and with the change above that also works.
From a Suite Perspective, Auth_SASL is available as a composer require option and I would think it would make sense to include it that way as a default to ensure its not needed at the server level.
SuiteCRM is in general a quite buggy system from my experience. Its a good system so do not get me wrong, but it has its share of annoying bugs like this one. But SalesAgility who is the maintainer is very slow to fix them if at all. Some bugs have been hangning there for years. So you need to figure it out yourself.
