Hi. I have setup ISPConfig on a conputer running Suse 10 (this is my first serious go at Linux), following the perfect setup instructions, and proceeded to test. I managed to send a web hosting user mails, and I can download them using POP3 and IMAP to a mail client (Mozilla Suite). It does not work when I try to do the same using POP3S or IMAPS. As described in the perfect setup, I am using the courier-pop-ssl and courier-imap-ssl daemons for that. Both are started, I double checked that. "netstat -tap" shows me: Code: tcp 0 0 *:imaps *:* LISTEN 4757/couriertcpd tcp 0 0 *:pop3s *:* LISTEN 5095/couriertcpd tcp 0 0 *:pop3 *:* LISTEN 5180/couriertcpd tcp 0 0 *:imap *:* LISTEN 4755/couriertcpd So I assume they are really listening to the correct ports. When Mozilla tries to connect to the server, it just mills a while, and then time-outs and returns that the server was disconnected. In the mail log appear lines like: Jan 6 00:17:11 mars imapd: Connection, ip=[::ffff:192.168.2.1] for the attempted imaps connections, simmilar for the pop3s ones. Has anyone an idea what could be wrong, or give me a hint on the way to the solution? Thank You.
Might be a firewall issue. Please post the output of Code: iptables -L Could as well be an issue with the certificates. Please have a look here: http://www.howtoforge.com/forums/showthread.php?t=1168
Thank You. I have, following the data out of the give threat, backed up the existing imapd and pop3d certificates, edited both cnf files to generate more correct certificates (with the real name of the mail server), and restarted the two mail daemons. This had not fixed the problem. Code: iptables -L returns Code: Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Ok, your firewall is not the problem (because it isn't turned on). Did you try to restart Courier and maybe even your whole system? Aren't there any more precise messages in your logs?
Related to courier and postfix I know of the "mail" log, which contains informations about the attempted connects and disconnects, but otherwise I am a complete Linux noobie. Are the any other logs I could check, have you any recomendation? Maybe some specific log Courier notes down its actions? Maybe I should mention that I encountered a bug in the Courier instalation on Suse 10, it does not per default assign the Courier SSL daemons to the correct ports, but to the non SSL ones. In the courier-pop3-ssl and couriter-imap-ssl daemon startup scripts were errors I fixed. I am wondering if anyone got ISPConfig working with courier on the released Suse 10, maybe there are additional glitches in there beside the wrong ports. Thank You. PS: I have restarted the system, now I have discovered following rather interesting entries in the mail log: Code: Jan 6 11:17:12 mars authdaemond: modules="authuserdb authpam authldap authcustom authpipe", daemons=5 Jan 6 11:17:12 mars authdaemond: Installing libauthuserdb Jan 6 11:17:12 mars authdaemond: libauthuserdb.so: cannot open shared object file: No such file or directory Jan 6 11:17:12 mars authdaemond: Installing libauthpam Jan 6 11:17:12 mars authdaemond: Installation complete: authpam Jan 6 11:17:12 mars authdaemond: Installing libauthldap Jan 6 11:17:12 mars authdaemond: libauthldap.so: cannot open shared object file: No such file or directory Jan 6 11:17:12 mars authdaemond: Installing libauthcustom Jan 6 11:17:12 mars authdaemond: Installation complete: authcustom Jan 6 11:17:12 mars authdaemond: Installing libauthpipe Jan 6 11:17:12 mars authdaemond: Installation complete: authpipe Jan 6 11:17:22 mars postfix/postfix-script: starting the Postfix mail system Jan 6 11:17:22 mars postfix/master[5252]: daemon started -- version 2.2.5, configuration /etc/postfix Another few facts: "telnet localhost 143" replies: Code: * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2005 Double Precision, Inc. See COPYING for distribution information. "telnet localhost 993" replies Code: * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=PLAIN ACL ACL2=UNION] Courier-IMAP ready. Copyright 1998-2005 Double Precision, Inc. See COPYING for distribution information. Shouldnt a normal telnet to port 993 be straightly rejected? "openssl s_client -connect localhost:993" replies Code: CONNECTED(00000003) 6868:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:494: The above implies that there is a daemon running on port 993, but its not supporting the SSL protocol? I cannot currently attempt to connect through a client to it, will try that in the later afternoon.
No, no other logs, it's the mail log... What did you change in the scripts? The ports are: 993 for IMAPS 995 for POP3S
Yes, thats what I did. The scripts used the constants $PORT, which were set to the 110 or 143, instead of the constants $SSLPORT, which were set to 993 and 995. Without that change courier SSL implementations did listen to the wrong ports. Now I am having the feeling they do listen to the right ports, but not using SSL encriptions, since I just had a nice conversation with the POP3 SSL daemon through normal telnet: Code: mars:/etc/courier # telnet localhost 995 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK Hello there. user test.inovabit.com_testie +OK Password required. pass <CENZORED> +OK logged in. list +OK POP3 clients that break here, they violate STD53. 1 1411 2 1402 . quit +OK Bye-bye. Connection closed by foreign host. I dont think this should have worked this way if encryption was active, right?
Both services, courier-pop-ssl and courier-imap-ssl are running and receiving traffic on the correct ports. To my limited knowledge though they seem to expect non-encrypted (non-SSL) traffic. If you look above, I initiated a telnet connection to port 995. I have been searching for a solution all over the net in the last day or so, the problem is that so far I found references of about 2 people having the same problem as me under Suse 10, but no data if they solved it and how, only simmilar posts as is mine on here. It seems in Suse 10 the courier scripts were changed, and by default they start on the wrong port, and when people fix it authorisation fails. I supose the next step is to find some old suse 9.x script and see if I can extract what is wrong with the 10 scripts. In case I do not manage to fix this bug... What would be the Linux distribution that would be recomended for ISPConfig? PS: Lovely. I cobbled together a complete solution to the IMAP part of the problem. The courier package scripts in Suse 10 are riddled with bugs. Now I will see if I can do the same for the POP3 part, then I will post the solution on here for any other poor soul after I tested it.
Any distribution that HowtoForge has a tutorial for, and also CentOS 4.1/4.2 (I haven't written a tutorial for CentOS yet, but I've been told it is working ). Personally, I recommend Debian. That would be great!
Once again, thanks for all the offered assistance. I would say Courier works well now after some testing. I get occasionaly a situation that looks like Mozilla keeps polling IMAP folders that are empty on the server, but that doesnt look critical. Here the solution how to get Courier POP3 and IMAP working correctly over SSL on Suse 10.0: This distributions comes with broken service start scripts courier-pop-ssl and courier-imap-ssl in /etc/init.d/. You can find the corrected scripts as attachments to this post. It is possible that the people at Suse will release a fix for that problem, but I have a feeling they will skip on that and it will be only come corrected with the upcomming 10.1 release.
your wrong - there are 3 people having the same problem! http://www.howtoforge.com/forums/showthread.php?t=2356 After searching and googling more than 1 day at all, we had the same idea at the same time and patched the /etc/courier/imapd-ssl and /etc/courier/pop3d-ssl files Your script courier-pop-ssl.gz (thank you!) won´t work at our system (I think mostly same configuration than your system), the courier-imap-ssl.gz we had´nt tested. If I use courier-pop-ssl.gz the courier-pop-ssl seems to be completly crashed Even /etc/init.d/courier-pop-ssl status /etc/init.d/courier-pop-ssl stop /etc/init.d/courier-pop-ssl start won´t give a result. After resetting to the original pop3d-ssl (from Suse10 perfect setup) the status/stop/start are giving the regular results. So here I post that both scripts propably patched a little bit different from your scripts. I didn´t checked out the differences, after 10 hours courier, postfix, pop and imap my nerves can´t anymore At the end now these services are working pop3-SSL (port 995) imap-SSL (995) smtp_auth with TLS (25) these service aren´t working pop3 TLS (25) imap TLS (25) pop3-SSL secure authentification imap-SSL secure authentification smtp_auth with SSL (465) I think that there is still a problem with the deamons running not on all ports they should. But at least, secure mail transfer is now possible and at next I will look to much other things to configure on our new system. There is much stuff to do ... hope that helps, too ....
Interesting. I am curious what the differences are between our two solutions, maybe we should provide a more general solution. Thank You for the contribution. Right now I am fighting to setup the PHP correctly to handle Postnuke...
Your both wrong, there are at least 4 people with this problem Did perfect install on clean new os install. All seemed fine, all checks during install did as documented. Now after a couple of reboots some stuff is not running and same issues as above. I am lookin at the scripts for the services now. MAJOR Bummer !!!! edit: Unless someone objects I would like to document my investigation here in this post with updates via editing, It might help someone else, keeps me from jotting notes all over the place and someone might notice something I missed or misunderstood. note that st20x files are the config files as found in /etc/courier and Traxus files are the acutal startup scricpts found in /etc/init.d made a backup copy of /etc/init.d/courier-imap-ssl and used Traxus file instead. Ran it with the restart command ares:/etc/init.d # ./courier-imap-ssl restart Shutting down Courier-IMAP (SSL) done Starting Courier-IMAP (SSL) done ares:/etc/init.d # netstat -tap tcp 0 0 *:imaps *:* LISTEN 3040/couriertcpd Woo Hooo !!! now have something listening at least. ok same thing with courier-pop-ssl. it runs now!!! chmod 755 ./courier-pop-ssl ares:/etc/init.d # ./courier-pop-ssl restart Shutting down Courier-POP3 (SSL) done Starting Courier-POP3 (SSL)unlimited done ares:/etc/init.d # netstat -tap tcp 0 0 *op3s *:* LISTEN 3572/couriertcpd
Okay, I've got the same problem. Courier-imap on SUSE 10, when trying to get imap-ssl working, is just broken. I'm fairly new to linux, and it would be great if someone could post a solution to the problem here. --- ERic
