>>Did you make sure you installed PHP with OpenSSL support? If you don't, >>the n the login will fail.
> good question. OpenSSL is on the server but I don't recall explicity > integrating it. OpenSSL is one of those things that I think isn't defaulted to being on, even most distributions leave it off, even if OpenSSL is detected on the system. > http://www.entropy.ch/software/macosx/php/test.php That one looks a lot better ;) Notice about 3/4 of the way down the page, the "openssl" section. That tells you the info you need. From that, it'd appear to be active now. > I'm likely to toss it on the server to see what happens. Do you see > the ssl flags you are looking for? Yep... I think you should be set to go if you use that setup now. It does include the OpenSSL libraries that time. > I noticed this: > '--with-openssl=/usr' That's the important line. > '--with-imap=../imap-2002d' '--with-imap-ssl=/usr' This one is irrelevant to us, we have our own IMAP handling functions so there is no dependancies on the PHP based ones. > perhaps simply having openssl inplace and active on the server > shortcircuited that problem while PHP's lack of support for it led to > the timeouts. Not sure what you mean, but usually if you try to call a function that php needs to use, that doesn't exist, then it generates an error. However, fsockopen is enabled by default, just the tls:// extension would be missing. I'm surprised it didn't fail, unless it picked it up as an unknown tcp connection, and handles it as plain text type connections. I'd prefer it to fail loudly, than fail in unusual ways, it makes fixing bugs easier that way ;) Having OpenSSL doesn't always guarantee it'll be included. I spent several hours trying to get PHP to compile with OpenSSL, it'd never fail the configure, or the make, but would not include the libraries... I don't exactly remember the solution now though. > logins and plaintext - sounds worth exploring a bit. maybe an option > to enable/disable plaintext and/or plaintext readback on error in the > config script? At any rate - looking forward to trying again, and > thanks for your help. Hrm... Well it depends at what point you mean I guess. Reporting an error, then yes, it'd probably be worth putting in a 'debugging' switch that will echo the full login attempts so you can see exactly what's going on. On a lower debug level (0), don't echo the username, just echo something like: QUERY: LOGIN *** *** With the characters masked/hidden/removed. There is a nifty little plugin called secure_login that is worth peeking at if you want to run SSL. You can set it up to automatically redirect users to the HTTPS login... You then have the choice as to stay in HTTPS, or bounce back to HTTP... I've not noticed that much of a difference when it comes to processing speeds, but I guess on larger servers, it might be worth just having the login as https. But then you tend to find some people will argue the point, if the login is encrypted, it means you must be trying to protect your mail (or something to that effect) but running the mails over plaintext defeats the point, as people could 'sniff' the emails on the plain text http connection. So the choice ends up being personal preference in the end. -- Jonathan Angliss ([EMAIL PROTECTED]) ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 -- squirrelmail-users mailing list List Address: [EMAIL PROTECTED] List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=2995 List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
