Inbound Email cannot function without the IMAP c-client libraries enabled/compiled with the PHP module.

SuiteCRM Forum - English Language SuiteCRM General Discussion
#1

Don’t Kill me for asking what might be a stupid question, and for the long details, but I could not find a solution for my problem…

So I am a bit confused. I do not understand why I have to enable imap if I am only sending, not retrieving? In the past, you could set up one outgoing email and everyone could use it - if it was selected as such via Admin set up. Recently we moved away from Gmail so I had to reset our email for the system.

The issue I am having now is that even though I have the relay working and have confirmed such via t the send test. My account which is an Admin account will not let me reset another users password. I get the Inbound Email cannot function without the IMAP c-client libraries enabled/compiled with the PHP module.

Eventually, it fails and times out with this error in the log file. “The outbound mail server selected for the mail account you are using is invalid. Check the settings or select a different mail server for the mail account.” Of course, I can not set up a user email account because Imap is not configured or working correctly.

So I went to enable find out what PHP was runing and where via root php -i | grep php.ini
and got this…
Configuration File (php.ini) Path => /etc/php7/
Loaded Configuration File => /etc/php7/php.ini

So when I add extension = imap.so at the bottom of the php.ini

I get this when tying to see if it is now enabled… via php -m
PHP Warning: PHP Startup: Unable to load dynamic library ‘imap.so’ (tried: /usr/local/lib/php/extensions/no-debug-non-zts-20170718/imap.so (/usr/local/lib/php/extensions/no-debug-non-zts-20170718/imap.so: cannot open shared object file: No such file or directory), /usr/local/lib/php/extensions/no-debug-n on-zts-20170718/imap.so.so (/usr/local/lib/php/extensions/no-debug-non-zts-20170718/imap.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0

Not sure Why it is trying to pull in the user php extensions, So I think maybe it is not installed.

so I look to see what the status is and what is actually running via systemctl status php-fpm.service
● php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled)
Active: inactive (dead)

But if I run it for the system php7-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/etc/systemd/system/php7-fpm.service; enabled; vendor preset: disabled)
Active: active (running) si

So I think it is not installed so I dnf install php-imap via root

and get this

Package php-imap-7.1.8-1.fc23.remi.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
[root@suite php7]# Package php-imap-7.1.8-1.fc23.remi.x86_64 is already installed, skipping.

At this point, I have no Idea what PHP version Suite is actually running or which modules are installed, or which php.ini I am to update to get email working.

Does anyone have any insight? What am I missing?

I don’t know what to do at this point to get the system to allow others to reset passwords or send emails.

I guess I could manually do it via hash. Does anyone know which Hash to use will md5 be sufficient? It looks like other users hash code starts with 1$1$ is that necessary?

#2

Normally there are two php.ini’s in your system, one for CLI (command-line) and one for the web server.

SuiteCRM uses the CLI for the cron jobs, if you set them up that way, and this affects deferred email sending (campaigns, reminders, etc) and workflows and a bunch of other things from the Scheduler jobs.

SuiteCRM uses the Web server for everything else you do from the UI.

You have probably been changing things for the CLI, try finding out your PHP configuration for web server. One way to do this is to get phpinfo from Admin / Diagnostics.

Phase out using the cli (for anything)
#3

just a curiosity.

Have you tried adding:

$sugar_config['allow_pop_inbound'] = TRUE;

in config_override.php to see if you can use pop instead of imap?

#4

Gave this a try and got the same error. Pop shows up in drop down but when I test I get the same IMAP error.

#5

PHP Info show loaded configuration as Loaded Configuration File /etc/php7/php.ini

This is where I set extension = impa.so and got the issue that it is finding extensions in the user folder i.e. /usr/local/lib/php/extensions/no-debug-non-zts-20170718

This is also what it says in php info for extension_dir

So I am not sure how to change that? Let me know if you have any tricks.

#6

we should not have to use any tricks to set up Email accounts. It should be just a snap.

It is known and documented in the forum that Email function is a weak point now in suitecrm.
We all hope that somebody will take over to fix these problems with rights and accounts, checkboxes spread over in different forms and forms who have an impact and others without and missing or misleading info’s in browser and log files.

furthermore anybody should be warned to upgrade from older versions because some of them will find themselves with Email troubles on production systems.
At least what I have found out and documented and what is written in the forum.

I´m still convinced that suitecrm is an excellent choice and that this Email situation can be cleared.

#7

@tseward ok, you’ve confirmed you’re editing the correct php.ini.

I’m not sure why you’re getting that PHP configuration error, maybe you’re better off asking on Stack Overflow or on some PHP forum… sorry if I don’t know enough to help you here.

About resetting the passwords from the database, use these instructions
http://support.sugarcrm.com/Knowledge_Base/Password_Management/Resetting_the_Administrator_Password_From_the_Database/

The basic mechanism is pretty simple: get the hash from a password which you know, and copy it into another user’s password field.

1 Like
#8

I agree. Biggest confusion for me is the selection box that others can use the account for outbound. That does not seem to be working in 7.9.8 or has been removed but the selection is still available.

The key is that I can get the system to send email and confirm that they are working through my relay but my individual email is not functioning when I try to do anything related to email and crashes the system. The system comes back but email does not work i.e. until I get the php-imap issue resolved. Which should be easy but has turned out to be a bear!

Seems like many hands in the open arch but not one QA to test various input fixes or the QA process is not robust enough to sniff out issues caused by one change and its dependency on another. I now dread a update or upgrade for fear of something breaking things that we rely on.

I am also still convinced that it is better than other solutions but at times is tough to justify with upper management who just expect it to work.

#9

Yea I figured that the manual approach part out but still having the PHP issue. Thanks for the reply.

#10

To both of you:

I am with you regarding the need to fix Email. It is my personal number one priority, I would say. The necessary steps that are being taken are these

  • better configuration screens, there were improvements in this but there’s still a lot to be improved

  • better automated tests! Regressions have hit us pretty hard whenever we touch email. If you watch GitHub you will see some of our main developers have been focusing on this, improving the test framework and adding tests

  • better SMTP logging: I personally studied this issue and made a PR about a month ago, even though my tasks don’t normally involve development

Sometimes it might seem like we’re not responding to everything you say, but I am reading everything attentively and in my head I am forming a better idea of what are the requirements (there are many different kinds of users out there) and where are the pain points. I am preparing a larger report on email redesign with all this.

Meanwhile, the way is forward, and every little bug report and every little fix counts to make Email more robust. Thanks for all your help in this, let’s keep it up until we reach excellence, no less.

#11

thank you pgr.
That sounds like a plan and is very much appreciated.

#12

there is as well Progress on the email LOG functionality in 7.10.4.

Thank you. Very much appreciated.