Email Bug

[tanya]

Check apache log and espocrm logs, run rebuild.php file from espocrm directory in terminal

[deant]

From apache error log...
[Thu May 04 09:27:35.169322 2017] [:error] [pid 1740:tid 932] [client 192.168.1.179:1258] PHP Fatal error: Call to undefined method Espo\\Hooks\\Common\\NextNumber::afterSave() in C:\\Bitnami\\espocrm-4.2.7-0\\apps\\espocrm\\htdocs\\application\\Espo\\Core\ \HookManager.php on line 125, referer: http://sales.schoolpride.com/espocrm/
[Thu May 04 09:27:35.169322 2017] [:error] [pid 1740:tid 916] [client 192.168.1.179:1259] PHP Fatal error: Call to undefined method Espo\\Hooks\\Common\\NextNumber::afterSave() in C:\\Bitnami\\espocrm-4.2.7-0\\apps\\espocrm\\htdocs\\application\\Espo\\Core\ \HookManager.php on line 125, referer: http://sales.schoolpride.com/espocrm/

from espo log...
[2017-05-04 09:34:09] Espo.ERROR: Uncaught Exception PDOException: "SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'Failed-2017-04-02 01:55:00' for key 'IDX_JOB_EXECUTE_TIME'" at C:\Bitnami\espocrm-4.2.7-0\apps\espocrm\htdocs\application\Espo\Core\Utils\ Cron\Job.php line 217 {"exception":"[object] (PDOException(code: 23000): SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'Failed-2017-04-02 01:55:00' for key 'IDX_JOB_EXECUTE_TIME' at C:\\Bitnami\\espocrm-4.2.7-0\\apps\\espocrm\\htdocs\\application\\Espo\\Core\ \Utils\\Cron\\Job.php:217)"} []


Do you want me to run the rebuild.php from....
C:\Bitnami\espocrm-4.2.7-0\apps\espocrm\htdocs\data\.backup\upgrades\589a3b 4e6903c\files
or
C:\Bitnami\espocrm-4.2.7-0\apps\espocrm\htdocs
...I found a rebuild.php in both of these folders.

[tanya]

Hello
Check in database, if IDX_JOB_EXECUTE_TIME in job table is UNIQUE (has not be)
rebuild.php in espo dir (second one)

[deant]

Thank you for helping me with the rebuild.php. Successfully upgraded to 4.6.0
Our email issue still exists though.
Where would I find the value for IDX_JOB_EXECUTE_TIME?

[tanya]

It's a name one of indexes in `job` table in database. This index hasn't to be unique. Your error message says it's unique key and duplicates are there.

[murugappan]

Dear Dean,

The software design and structure is fantastic. Its much more simpler than Suitecrm which has deplorable documentation and lousy support. Too complicated too. It needs a real professional hacker to get Suitecrm to work. The support here for espocrm also sucks! Many of the questions are still left hanging, if not outdated. Seems like if they dont know the answer, they just keep quiet and hope for you to sign-up for pay-support. Sigh! How do i do that when the basics dont work??

Coming to your problem, we had the same. The email in the inbox say "body not fetched". After some struggling, we found out why. It was the cron job scheduler within espocrm. Its under admin function. You have to play around the "mail fetching" scheduler and get the right timing. What is happening is that, when the scheduler is to too quick, while one cron job is running and fetching, another one gets triggered by espocrm which goes for the same email from the external mailbox. Conflict happens and cron skips fetching the complete email.

This is what happen to us. So we retimed the scheduler and now runs well. You will hit the same snag with mass mailing as well. You would find partial mailing only. Suggestion break-up the target list into smaller packets.

Hope this helps.

[fancymedia]

Murugappan, can you share your cron settings? we tried several combinations but were unable to make it work. Thanks, Chris.

[brotherlouie]

I'm experiencing a similar issue and wondering if anyone has seen this before.

Environment:

* EspoCRM 9.3
* Ubuntu 24.04
* PHP 8.3
* IceWarp IMAP server (SSL/TLS, port 993)

The strange part is that everything appears to work correctly:

* IMAP Connection Test is successful.
* Webmail login works.
* Outlook login works.
* Emails are actually being fetched into EspoCRM.

However, every 5 minutes I get the following log entry:

EmailAccount [ID], could not select folder 'INBOX';
IMAP command "TAG1 LOGIN" failed.
Response: "TAG1 NO LOGIN Unknown user or incorrect password"

What I already tested:

* Recreated the email account from scratch.
* Changed the mailbox password.
* Cleared cache and rebuilt.
* Removed all email filters.
* Removed old jobs related to deleted email accounts.
* Verified IMAP login manually from the server using openssl.

The most interesting finding:

When I disable the scheduled job "Check Personal Email Accounts", the log entries stop completely.

When I enable it again, the errors immediately return every 5 minutes.

Has anyone experienced this with Personal Email Accounts, IMAP polling, or IceWarp mail servers?

Any ideas would be greatly appreciated.

[shalmaxb]

The error message "TAG1 NO LOGIN Unknown user or incorrect password" comes from the IMAP server, indicating authentication failure. Since manual login works, the issue is specifically with how credentials are retrieved during automated polling. The 5-minute interval corresponds to the scheduled job frequency.

Check your password, if it has any special character, change to a simple password for testing.

[yuri]

Do emails stop being imported at all or it's an error that occurs regularly but not each time?

[brotherlouie]

Emails are still being imported. They do not stop completely.

The error occurs regularly when the “Check Personal Email Accounts” scheduled job is enabled.

What I observed:

* Personal Email Account enabled + scheduled job enabled → the error appears regularly.
* Personal Email Account enabled + scheduled job disabled → the error stops.
* Emails are still fetched/imported despite the error.
* Connection Test is successful.
* Webmail login works.
* Outlook login works.
* Manual IMAP login from the server works.
* I also changed the password and re-saved the account.

An additional observation:

Initially the scheduled job was running every 1 minute. Later I changed it to every 5 minutes, but the error still occurred.

I have now changed it to every 15 minutes. The job has already run several times (about 45 minutes of testing) and so far no new login errors have appeared in the log. However, in previous tests some log entries appeared with a delay, so I am still monitoring it.

This makes me wonder whether the issue could be related to polling frequency, overlapping IMAP connections, or a scheduler timing problem rather than actual authentication failure.

The log example:

EmailAccount [ID], could not select folder 'INBOX';
IMAP command "TAG1 LOGIN" failed.
Response: "TAG1 NO LOGIN Unknown user or incorrect password"
:: /application/Espo/Core/Mail/Account/Storage/DirectoryTreeStorage.php(317)




Small update:

After increasing the polling interval from 5 minutes to 15 minutes, the error frequency decreased significantly, but the issue is still present.

The scheduled job ran successfully multiple times without errors, but eventually the same IMAP LOGIN error appeared again:

EmailAccount [ID], could not select folder 'INBOX';
IMAP command "TAG1 LOGIN" failed.
Response: "TAG1 NO LOGIN Unknown user or incorrect password"

So increasing the polling interval appears to reduce the occurrence, but does not eliminate it completely.