Email Bug

[deant]

zend-mail library can't handle response from the imap server. I've never run into this error before

[2016-11-29 14:41:55] Espo.WARNING: E_WARNING: Invalid argument supplied for foreach() {"code":2,"message":"Invalid argument supplied for foreach()","file":"C:\\Bitnami\\espocrm-4.2.7-0\\apps\\espocrm\\htdocs\\vendor\\zendframework\\z end-mail\\src\\Protocol\\Imap.php","line":803,"context ":{"params":["UID 2:*"],"response":true}} []

So, any suggestions how we can troubleshoot this zend-mail library issue? our IMAP server is very normal as far as I know. Nothing too exotic about our email setup here.

[yuri]

You can debug in this file vendor\\zendframework\\zend-mail\\src\\Protocol\\Imap.php

[deant]

Upgraded to Espo 4.3.0 today. Problem still exists. Any help troubleshooting the issue would be appreciated.

[yuri]

1. Try to install mailparse extension.
2. Try to debug here vendor\\zendframework\\z end-mail\\src\\Protocol\\Imap.php

[deant]

Installed php mailparse extension and enabled it in php.ini, but nothing new to report there.
As for debugging the Imap.php file, i'm not entirely sure how to do this. However I did do some experimenting with my IMAP server using telnet and found that...

? FETCH <uid_of_desired_message> All

does not return the body of the message, but returns everything else that Espo gets also. If I use...

? FETCH <uid_of_desired_message> BODY[1.2]

Then only the body is returned. I'm hoping that with this information someone may know what needs to be changed in my imap.php file as i am still very new to PHP and can only find a small section in imap.php concerning "fetch".

[yuri]

It's not about php. It's a command being sent to IMAP server. This code is located in zend framework library that might have bugs.

[deant]

Great, How do we move forward with Espo? Or are you saying this software is unsuitable for real use?

[yuri]

Your issue never happened before, at least I've never noticed such an issue reported. You've chosen installation on your local server. There can be A LOT OF OBSTACLES for software that we can't foresee. Environments are different. If you helped us to find out where is the problem it would be great for everybody.

You could opt to any non open source software to have all issues handled by paid support.

[deant]

Right, that's why I chose the Bitnami install, that way any dependencies and configs necessary for a vanilla Espo would be available right away.

As for solving this issue. I'm not sure where to really start. But I did a bit more troubleshooting. We set up a gmail account to use with Espo, and it can read the emails associated with that account no problem. The problem seems to be specific to the IMAP server we use, which is strange because its using the most common and current IMAP protocol, 4rev1. There shouldn't be anything exotic about the way our IMAP server is communicating.

[yuri]

If I had credentials to any mailbox on your IMAP server I would investigate.

[deant]

Excuse me but I am not comfortable, and will never be, handing over login credentials for our hosting to a stranger. Could you be more specific as to what sort of things you might investigate on the hosting side so that we may look into it ourselves?

Updated to version 4.4.1, problem still exists.

[deant]

Good morning Yuikuzn, We've decided to create a test mailbox for investigation into this issue.

I spoke with Joseph from CloudAccess Support (the company hosting our email) for ~50 minutes. We tried troubleshooting a few things and he had their system administrators verify that messages are being sent back intact from the IMAP requests being sent.

Joseph suggested that perhaps espo is attempting to read the messages in some way that cloudaccess is not currently supporting. The example he gave was that CloudAccess may be sending the messages in format “A, B, C” while espo may be looking at these as “A, D, E” whatever these differences may be or something along these lines. Which is close to what you and I seem to have been thinking as well. As far as what these differences may be, he and I are both at a loss to know. The CloudAccess IMAP server is following IMAP protocol version4rev1, just like the Google IMAP server or the NameCheap IMAP server (another hosting service that is working fine with EspoCRM), and really any IMAP server today that follows industry standards laid out for IMAP as recently as 2003.

Your insight to this matter would be much appreciated. Let me know if you are willing to participate in the continued troubleshooting of this matter, and I will send you login credentials to the test mailbox.

[yuri]

What I observed when tested connection w/ your imap.

Request sent:
TAG1 LOGIN "USERNAME" "PASSWORD"

Response received:
CAPABILITY IMAP4rev1 AUTH=CRAM-MD5 UIDPLUS XLIST IDLE

[deant]

Thanks for looking into this Yuri.
Sorry I haven't replied sooner. I didn't think to come check here for your findings. Any suggestions on what needs to be changed in order to get Espo and the IMAP server communicating more effectively?

[deant]

The situation has gone from bad to worse. While espo is still failing to retrieve emails, upgraded from version 4.4.1 to 4.5.1. The upgrade completed successfully, but now an error 500 occurs at login. No one can log in. The product has completely failed at this point. How do you expect to sell a more elaborate version of this product when it doesn't function in its simplest form?