Roundcube freezes trying to open message

[stant]

On FreeBSD 7.0 with Dovecot I've got the following message in logs:
[19-Nov-2009 17:05:19] PHP Fatal error: Maximum execution time of 120 seconds exceeded in /usr/local/www/roundcube/program/lib/imap.inc on line 1850

This happens when I click on message header to open it and Roundcube show "Loading..." hint and freezes. Some messages were opened normally.

[alec]

Enable imap_debug option and attach logs/imap here.

[stant]

IMAP log-file (freezing problem)

[stant]

IMAP log-file (login problem)

[stant]

I've posted two logs. The first one is when I have described problem.

The second one is a new problem which I have since upgraded roundcube from 0.2 to 0.3 version. I able to login only after few failed attempts. Each failed attempt was attended with "IMAP connection failed" message and the following record in log-file:
[19-Nov-2009 16:48:41] PHP Warning: mcrypt_generic_init() [<a href='fpunction.mcrypt-generic-init'>function.mcrypt-generic-init</a>]: Iv size incorrect; supplied length: 12, needed: 8 in /usr/local/www/roundcube/program/include/rcmail.php on line 995
[2009-11-19 16:48:41 +0300]: IMAP Error: Authentication for stant-bestyle.ru failed (LOGIN): "a001 NO Authentication failed." (GET /?_task=mail)

I believe I must describe this new problem in the new ticket but maybe this caused by the same problem as first, so I won't create excess tickets.

[alec]

I don't see in imap.freezes any problem.

[stant]

Yes, I looked it too and don't see any problem too. Maybe it's UI problem, AJAX or maybe something else?

[stant]

Screenshot

[stant]

Comment to screenshot. Before that I clicked other messages and they were opened. Then I clicked message which selected on the screenshot, "loading..." message appeared on the top and it froze. After about 30 seconds I took screenshot.

[alec]

This could be also a http connection issue. It happens with one or any message? How often this happens? But if you have "Maximum execution time of 120 seconds exceeded in /usr/local/www/roundcube/program/lib/imap.inc on line 1850", you should also have something strange in the imap_debug log.

[stant]

I discovered more info. It happens only with certain messages, but I didn't found any regularity. Now I sure this IMAP related problem. PHP freezes on fgets line in function iil_ReadLine which is located in program/lib/imap.inc (I'll attach trace log). In that momement there was "ftch0 OK Fetch" line in 'logs/imap'. You can see it by timestamps:

[2009-11-23 16:48:04 +0300]: S: )                                                                                                           
[2009-11-23 16:48:04 +0300]: S: ftch0 OK Fetch completed.                                                                                    
[2009-11-23 16:51:11 +0300]: S: * OK Dovecot ready. 

[stant]

PHP trace log

[alec]

PHP bug or connection is closed by server. We should add feof() check in iil_ReadLine(), but I'm not sure if this will fix your issue.

[alec]

Please try [35b01b64] change.

[stant]

I tried [35b01b64] and the latest revision also. The issue still not fixed.

[stant]

But now I don't see any problem in imap logs. The message was fetched completely but not displayed. Maybe it's UI problem?

[alec]

Enable preview pane and try again. Also ypou could attach the message here.

[stant]

I've created mail account for testing:
​http://mail.bestyle.ru
login: test
password: rc1486307

But you will probably need a few login attempts to enter (​http://trac.roundcube.net/ticket/1486307#comment:2). There is one message in it and it will completely freeze the RC. You can try firebug it.

[alec]

I've connected my Roundcube box to your IMAP server and "'ve no problems with this message. So, what www server/php versions are you using? Are you using secure IMAP connection? We need more info.

[alec]

Also no problem here with logging in.

[stant]

PHP Version 5.2.9
Apache/2.2.6 (FreeBSD)
Dovecot 1.0.14

I'm using secure IMAP connection. Here's the part of main.inc.php:

$rcmail_config['default_host'] = 'ssl://localhost';
$rcmail_config['default_port'] = 993; // 143
$rcmail_config['imap_auth_type'] = null;
$rcmail_config['imap_root'] = null;
$rcmail_config['imap_delimiter'] = null;
$rcmail_config['username_domain'] = '';

[alec]

No problem with ssl too. Try to upgrade dovecot or PHP.

[stant]

Upgraded Dovecot to 1.2.4, PHP to 5.2.11 (full info here: ​http://test3.bestyle.ru/.phpinfo.php) Reinstalled roundcube from ports. No effect.

[youknowwho]

I am experiencing the same issue. I am able to authenticate >some< of the time. I also have the same logs in the log file, like so:

#############################################################
[16-Mar-2010 23:40:31] PHP Warning: mcrypt_generic_init(): Iv size incorrect; supplied length: 9, needed: 8 in /path/to/my/webroot/roundcube/program/include/rcmail.php on line 1107
[16-Mar-2010 16:40:33 -0700]: IMAP Error: Authentication for david@… failed (LOGIN): "a001 NO Authentication failed." in /path/to/my/webroot/roundcube/program/include/rcube_imap.php on line 139 (GET /roundcube/?_task=login)
#############################################################

However, >sometimes< the login succeeds, and when it does, there is no log entry concerning authentication. It seems like it's a decryption problem in the code; as if the mcrypt doesn't properly decrypt the user's password in "rcube_imap.php" (or maybe never encrypt it properly in the first place???) and of course, as a result, authentication fails (wrong password) but the user interface doesn't say the login failed, it says "connection to imap server failed". The connection isn't failing - I can capture the imap traffic using pcap on that interface and there is a perfectly good tcp stream of data on TCP/143, and following the stream shows the incorrect password and auth failure from the imap server.

When the authentication does succeed, it's as if the password was perfectly decrypted (the password is shown in the tcp stream in cleartext) and then everything else seems to work after that. However, after logging out, one cannot log back in again, due to the same problem.

First, I thought maybe hacking up the code and removing the mcrypt stuff, but then I realized that this would be a bad thing, and a very bad idea, because it would expose the user's password in cleartext in their cookies.

There must be some way to fix this. Any help would be greatly appreciated.

My setup is as follows:

1. I am using roundcubemail from yesterday's SVN, from 3/15/2010 (rev. 3363), but I have also tried the latest release (roundcubemail-0.3.1.tar.gz), and I experience the identical result (except that the error in the log implicates line 995 on the release, instead of 1107 in the SVN).

2. I am using apache 2.2

3. I am using PHP 5.2.11

4 I am using Dovecot 1.0.1.4 (yeah I know).

5. I am using mysql 5.0.45.

6. The configuration is set to pass "%u" and "%p" variables onto the imap/smtp boxes.

7. libmcrypt version is 2.5.8.

8. php5-mcrypt is also 5.2.11

9. mcrypt version is 2.6.6.

10. Like the other user's post, the log entries also vary from 9, 10, 11, 12, and so on. I suppose when it's "8" is when one is lucky enough to have passed the login screen.

11. I have assigned a 24 character string for the key variable, differing from the default key. I have counted the number of characters in the value at least 3 times, and still arrive at count of 24. Also, even if I left the key to the default 24 characters, this problem still exists. This is probably irrelevant for this problem, but just in case anyone wants to know.

12. TCP/80 to TCP/443 redirection/rewriting. I know that you can redirect https via configuration file. I have chosen to do it in the .htaccess file instead. Maybe this is irrelevant, but I wanted to mention it, just in case. I am redirecting TCP/80 [http] to TCP/443 [https] VIA appending the .htaccess file. The appending is as follows:

Options -Indexes
ErrorDocument? 404 /index.html
DirectoryIndex? index.php
RewriteEngine? On
RewriteCond? %{HTTPS} off
RewriteRule? (.*) ​https://%{HTTP_HOST}%{REQUEST_URI}

13. If I really do type the wrong password, I get "Login failed." If I type the correct one, I get "connection to imap server failed" most of the time (90% - I cannot duplicate what "makes it work" some of the time).

14. For troubleshooting purposes, I have set "plain' for the imap auth type in the config file. The dovecot box supports the plain auth. For this case, the TCP stream on 143 always shows "auth plain" every time. Whether success or failure, the stream still shows "plain". When it works, the stream shows the correct password. The other 90% of the time, the authenticating username is shown in the clear, but the password is scrambled (incorrectly decrypted maybe).

15. Like the other user's post, occasionally, I experience a "hang" on the application after logging in. I suppose that the session may have expired by this time or something else has again caused the mcrypt piece to stop working again at the point of the "freezing."

16. Again, please note, authentication is successful, SOMETIMES. What gives?

Also, I should note that Horde/Imp? frontends work perfectly (and have been working fine for more than a year now). I have tested other frontends, openwebmail, and they seem to work fine too. This is probably something to do with the mcrypt, or other ciphering (or lack thereof) or entropy, or something related to the hashing of the user's password.

Please tell me if there is something I missed or another piece of different data that I could provide that would help solve this problem. Thanks in advance for looking into it.

I love this program - many thanks to those roundcube developers and maintainers! Hat's off to you.

[alec]

This maybe related to session handling, so enable sql_debug. Also do debug in rcmail::decrypt and rcmail::encrypt (eg. using console()) to what is passed to and returned from them.

[youknowwho]

I have fixed the problem. mbstring_overload was equal "2" in the php.ini file; the installer is what finally led me to the fix (I had never used the installer).
After setting mbstring_overload to zero, it works perfectly, but only with that SVN revision I mentioned (rev3363). I have not tested with latest rev.

[stant]

I confirm this solution.

Unfortunately, in the latest PHP versions mbstring.func_overload option is not configurable in the per-directory context. On my hosting mbstring.func_overload option is globally set to 7. Nevertheless I found that it can be changed in the apache <virtualhost> with the "php_admin_value mbstring.func_overload 0" directive. So this problem solved for me. But I think it will be less problematic if rouncube supported mbstring.func_overload.

[youknowwho]

Thanks for that solution also; I was wondering how to do it on a per-directory basis as well. I don't recall for which ap in which I set it to 2, but I suppose i will find out next time I try to use that ap. :)
I agree - mbstring_overload should be supported in some way. Something like this might require a major code rewrite.
In any case, I am happy we got to the bottom of it because RC is COOOOOOOOOOL.

[alec]

Too much work to support mbstring.func_overload. Added additional check in [cd96fd67].