HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials - Courier IMAP & POP without SSL work, but not with SSL.

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)

- Installation/Configuration (http://www.howtoforge.com/forums/forumdisplay.php?f=16)

- - Courier IMAP & POP without SSL work, but not with SSL. (http://www.howtoforge.com/forums/showthread.php?t=1938)

Courier IMAP & POP without SSL work, but not with SSL.

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.

Quote:

Originally Posted by Traxus

A complete restart of the system did not help. 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?

No, no other logs, it's the mail log...

Quote:

Originally Posted by Traxus

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.

What did you change in the scripts? The ports are:
993 for IMAPS
995 for POP3S

Quote:

Originally Posted by falko

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?

Did you have a look into

Code:

yast

if there's something you can do to enable IMAPS and POP3S?

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.

Quote:

Originally Posted by Traxus

In case I do not manage to fix this bug... What would be the Linux distribution that would be recomended for ISPConfig?

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.

Quote:

Originally Posted by Traxus

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.

That would be great! :)