No response.  Looks like a PHP build issue anyway - our code looks good.

I would try doing a 'make distclean' in the PHP source (or downloading 
a brand new source package), running configure/make again, and see if 
that fixes it.

Thank you for your feedback. It certainly explains most of the 
observations I have made; however, it is not enough to find the real 
cause of my problem.
That message points me into a blind alley (at least into an alley 
whose exit I cannot find).
Apparently, my PHP envirinment complies with this requirement, as 
phpinfo() says:
...
...
And horde/test.php says:
...
...
So either both phpinfo and horde/tes.php are wrong, or the cause of 
the problem is located elsewhere.



Both I am using an SSL-enabled version of c-client and the mail server 
supports IMAP over SSL, as has been demonstrated by horde/imp/test.php



What could I possibly try next to locate the cause of the problem?

Because it is using the c-client only, not the PHP-based IMAP client.
Because c-client rejects the login before we even have an opportunity 
to call the PHP imap client.
If that is the case, then there is something borked in your PHP install.
That is a totally bogus statement.



Directly from servers.php.dist:



*           The ssl and tls options will only work if you've compiled PHP

*           against a SSL-enabled version of c-client, used the

*           --with-imap-ssl and --with-openssl flags when compiling PHP,

*           and you have a mail server server which supports SSL.

I guess I'm confused.  Why isn't the Util::extensionExists('openssl') 
call earlier in the connect function returning false?  Because that is 
*exactly* the check required.

To  me, that message makes no sense at all, given that

- imp/test.php connects to the server via SSL without any problem, and 
tells me the number of messages in my mailbox,

- imp/login.php gets a sensible response from the server when the user 
credentials are wrong,

- test.php, imp/test.php, and phpinfo() unanimously report that SSL 
support is available, and sufficient, in my PHP installation.



I rather conjecture that Imp 4.1.3 uses some particular feature of PHP 
5.1's SSL support, which is not present in earlier PHP versions (in 
contrast to the documentation in imp/servers.php.dist). However, I 
have not the knowledge to prove, or disprove, that conjecture.

This message can't be clearer. But we should actually catch it and 
display it to the user and send it to the log.

Apparently, there is either an incompatibility between Imp 4.1.3 and 
PHP 4.4.2, or a problem with my PHP installation -- in spite of the 
successful SSL connection in the case of the wrong password.



From the PHP error log:

PHP Warning:  fsockopen(): no SSL support in this build in 
/opt/test-webmail/horde/imp/lib/IMAP/Client.php on line 321

PHP Warning:  fsockopen(): unable to connect to 
mail.inf.uni-konstanz.de:993 in 
/opt/test-webmail/horde/imp/lib/IMAP/Client.php on line 321

PHP Notice:  Undefined index:  registry.php in 
/opt/test-webmail/horde/lib/Horde/Registry.php on line 176



Note that the documentation (quoted in the attachment) explicitely 
recommends imap/ssl with pre-5.1 PHP, as does imp/test.php.

I forgot to mention:

- Horde: 3.1.3

- Imp: H3 (4.1.3)

- Turba: H3 (2.1.3)

- PHP Version: 4.4.2 (according to horde/test.php)

                4.4.1 (according to »pear -v«

- PEAR Version: 1.4.10

- Zend Engine Version: 1.3.0

- SunOS thurn 5.9 Generic_118558-38 sun4u

When I try to login to an IMAP server via imap/ssl/novalidate-cert, I 
receive the message "Error connecting to IMAP server: [0] Error 0" 
both in the user interface and in the Horde log; that message 
originates on line 345 of imp/lib/IMAP/Client.php.



However when I try the login with a wrong password, I get the correct 
"Authentication failed" message which clearly shows that the SSL 
connection works. On the other hand, I can login to the very same 
server via imap/notls, without any problem, so the 
imap/ssl/novalidate-cert protocol must somehow be involved in the 
error outlined above.



The imp/test.php page can login to that server both via imap/notls and 
imap/ssl/novalidate-cert, without any problem, which clearly shows 
that the installation prerequisites (such as  an SSL-enabled version 
of c-client) are met.



Attached is a text file containing:

- traces of the custom hook function arguments, and results, for three 
login attempts as outlined above,

- the recommendation of the imp/test.php script,

- the pertinent declarations from imp/config/servers.php.