Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 Description of problem: When trying to open mailbox at php 7.1.2 with imap_open Couldn't open stream error message appears. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: #!/usr/bin/php <?php printf("%s\n", imap_open ("{server.fi:143}", "username", "password")); ?> Actual Results: X-Powered-By: PHP/4.1.2 Content-type: text/html <br> <b>Warning</b>: Couldn't open stream {server.fi:143} in <b>php.php</b> on line <b>2</b><br> Expected Results: it should print the imap stream number (and do at red hat 7.2) Additional info: It is impossible to use imp(horde) mail program because of this problem.
This is caused by a change of behaviour. Even if you don't ASK for ssl negotiation, the connection will always try and negotiate ssl and when the client tries to validate the server's certificate, it fails. The script is *almost* correct. The problem is that the imap/ssl interaction uses a self signed certificate that we supply that instead of being signed by a cert authority, ergo the ssl connection will fail because it's not signed by a trusted authority. You need to change the mailserver from "hostname.com:143" to "hostname.com:143/novalidate-cert"; and suddenly everything will be fine again.. or you could go pay lots of money to a key certificate authority (CA) and get yourself a certificate that will pass the validation checks. Phil =--=
*** Bug 65201 has been marked as a duplicate of this bug. ***
*** Bug 65403 has been marked as a duplicate of this bug. ***
This is *definitely* a bug. At least 99% of Red Hat Linux users install imapd with a default, self-signed certificate. PHP's IMAP-SSL module should either be: 1) disabled by default, so that SSL is not used unless requested, or 2) if a self-signed certificate is encountered, by default fall back to non-secured operation or: 3) imapd does not generate a (self-signed) certificate by default, so there should be no problems(?) Ie. you break all the PHP-IMAP codes by enabling this broken SSL-IMAP. Not a good thing. I wonder what the authors were thinking: changing all the previously-working codes is not an option IMO.
*shrugg* Upstream change, not much I can do about it Phil =--=
*** Bug 72941 has been marked as a duplicate of this bug. ***
I am not really sure that Bug 72941 is the same like this. The tips above do not help. However, I tried to reproduce on RH73 and here I get the following error message upon imap_open( "{server:110/pop3}INBOX", "user", "pw" ). > Retrying CRAM-MD5 authentication after Bad user name or password
$mbox = imap_open ("{localhost:110/pop3/notls}", "user_id", "password"); Worked fine here. Phil =--=
erm sorry that should have been imap_open ("{localhost:110/pop3/notls}INBOX", "user_id", "password");