# Cannot connect using imap to postfix/courier-imap anymore

## vespaman

OK, so this is kind of a silly question   :Embarassed: 

Many years ago I installed postfix/courier-imap as well as roundcube on my main server, and it has been working flawless until last week, presumably it broke with a world update.

Since it was so many years ago, I have forgotten the relationship between all the mail stuff, and therefore I am not sure where to start looking.

The good thing is that roundcube works just fine; I can send and receive mail using it. 

With clients there are trouble when connecting using ssl.

If I use plain unencrypted imap it also seams to work, at least with thunderbird, kmail freaks out, but it was a long time since I could rely on kmail, so I think this should be disregarded.

If I try to use ssl, the only error that I get in the server log, is:

```
May 17 09:21:22 oxygen imapd: Connection, ip=[10.1.200.50]

May 17 09:21:22 oxygen imapd-ssl: couriertls: /etc/ssl/certs/bccd5223.0: No such file or directory

May 17 09:21:22 oxygen imapd: Disconnected, ip=[10.1.200.50], time=0

```

Could this be related, this seams to be a root certificate from diginotar, which has been revoked. Not sure how to remove this from my server?

As you can see, there's no "Login" in the log, so apparently very little is going on after connect..

----------

## cach0rr0

im assuming this is imaps on 993 and not starttls on standard imap

honestly? i havent a clue where the courier config files are, but if i were, for example, tasked with figuring out someone else's system with unfamiliar IMAP systems, my port of call would be:

-do a netstat -tlnp and see what's listening where. A runtime configuration error could mean the listener never loads, which would lead me to

-running an 'equery files courier-imap' to figure out where the deuce the config files are, followed by:

-thumbing through the init script and relevant /etc/conf.d/* bits. I would start up the daemon with the same command line args found between the two places, and replicate the beahaviour, hoping for a more meaningful error. if I didn't get one, I'd do the same under strace

other thing to do, nail down if the issue really is specific to encrypted connections. Check standard SSL vs STARTTLS, check 143 vs 993, see what works, then we can figure out what doesnt. 

vague reply? indeed! Those are starting points and thinking points. More log data would certainly be helpful, as well anything you can find from the pieces of suggestion above

----------

## vespaman

OK, so I really appreciate that my data is .. vague ..   :Smile: 

Here's the output from netstat;

```
oxygen postfix # netstat -tln

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address           Foreign Address         State      

tcp        0      0 0.0.0.0:35137           0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:17993           0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:15050           0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:51498           0.0.0.0:*               LISTEN     

tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:2222            0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:45104           0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:55153           0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:54106           0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:9981            0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:2525            0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:9982            0.0.0.0:*               LISTEN     

tcp        0      0 0.0.0.0:41022           0.0.0.0:*               LISTEN     

tcp6       0      0 :::139                  :::*                    LISTEN     

tcp6       0      0 :::2222                 :::*                    LISTEN     

tcp6       0      0 :::35726                :::*                    LISTEN     

tcp6       0      0 :::111                  :::*                    LISTEN     

tcp6       0      0 :::80                   :::*                    LISTEN     

tcp6       0      0 :::25                   :::*                    LISTEN     

tcp6       0      0 :::443                  :::*                    LISTEN     

tcp6       0      0 :::445                  :::*                    LISTEN     

tcp6       0      0 :::2525                 :::*                    LISTEN     

```

The ports 2525 and 17993 are also open doing 25 & 993 since my internet router does not allow me to do the required port remapping.

So server is listening at 993.

You don't reckon the misbehaving root certificate is part of the problem here?

As far as I can tell, neither STARTTLS nor SSL works.

The config files for courier are in /etc/courier-imap/ but I cant really conclude a problem with them. And I have not been able to find an option increasing details/logging information.

Will try to start courier-imap-ssl from command line as suggested!

 Thanks,

  Micael

----------

## cach0rr0

the '-p' switch on netstat especially helpful (did i omit that? I'll look after I post this...)

id wager if it's able to listen at all on 993, the cert isnt breaking anything

starting manually from CLI would be helpful

also using openssl's s_client would be helpful, e.g.

```

openssl s_client -connect x.x.x.x:993

```

(where x.x.x.x is your machine's IP obviously)

just to see if you can get a cert, or if the connection immediately dies. 

if that DOES connect, you should be able to issue IMAP commands just as you would via telnet (google around for 'test imap telnet')

for the non-ssl ports, a plain old telnet localhost 143 should work

that'd be where i went with it

----------

## vespaman

OK bad copy-paste lost the 'p'

```
Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    

tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN      1879/couriertcpd    

tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN      -                   

tcp        0      0 0.0.0.0:34023           0.0.0.0:*               LISTEN      -                   

tcp        0      0 0.0.0.0:17993           0.0.0.0:*               LISTEN      1879/couriertcpd    

tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1569/mysqld         

tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      2102/smbd           

tcp        0      0 0.0.0.0:2222            0.0.0.0:*               LISTEN      1745/sshd           

tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      1857/couriertcpd    

tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1629/rpcbind        

tcp        0      0 0.0.0.0:58098           0.0.0.0:*               LISTEN      1694/rpc.mountd     

tcp        0      0 0.0.0.0:59795           0.0.0.0:*               LISTEN      1694/rpc.mountd     

tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      1597/dnsmasq        

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      2087/master         

tcp        0      0 0.0.0.0:44379           0.0.0.0:*               LISTEN      1694/rpc.mountd     

tcp        0      0 0.0.0.0:9981            0.0.0.0:*               LISTEN      2122/tvheadend      

tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      2102/smbd           

tcp        0      0 0.0.0.0:2525            0.0.0.0:*               LISTEN      2087/master         

tcp        0      0 0.0.0.0:9982            0.0.0.0:*               LISTEN      2122/tvheadend      

tcp        0      0 0.0.0.0:34111           0.0.0.0:*               LISTEN      1643/rpc.statd      

tcp6       0      0 :::139                  :::*                    LISTEN      2102/smbd           

tcp6       0      0 :::2222                 :::*                    LISTEN      1745/sshd           

tcp6       0      0 :::111                  :::*                    LISTEN      1629/rpcbind        

tcp6       0      0 :::80                   :::*                    LISTEN      1759/apache2        

tcp6       0      0 :::25                   :::*                    LISTEN      2087/master         

tcp6       0      0 :::443                  :::*                    LISTEN      1759/apache2        

tcp6       0      0 :::44859                :::*                    LISTEN      -                   

tcp6       0      0 :::445                  :::*                    LISTEN      2102/smbd           

tcp6       0      0 :::2525                 :::*                    LISTEN      2087/master         

```

openssl s_client gives

```
$ openssl s_client -connect oxygen:993

CONNECTED(00000003)

write:errno=104

---

no peer certificate available

---

No client certificate CA names sent

---

SSL handshake has read 0 bytes and written 322 bytes

---

New, (NONE), Cipher is (NONE)

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

---
```

Haven't been able to start from commandline, too many options to satisfy.

Telnet connects on 993, but server closes down immedialetly:

$telnet oxygen 993

Trying 10.1.200.8...

Connected to oxygen.                                                                                                                  

Escape character is '^]'.                                                                                                             

Connection closed by foreign host.

Looking at the output from openssl s_client, I guess this somehow is a cert issue. What's bothersome is that the logs are so silent.

Edit: I have regenerated the imap cert with mkimapdcert but this did not change anything.

----------

## cach0rr0

"did not change anything" - i assume you used s_client again to test? 

with most IMAP systems, it's supposed to be a simple matter of editing a conf file, adding a line to point to cert, editing a line to point to key, done and done

i dont know how specifically one does this with courier (i use cyrus+postfix). Thing is, once you get a cert to show up with s_client, it's just like any other IMAP server. 

SO, piecemeal - does the cert show in s_client now? If not, we're missing something in the .conf one would assume. Does the cert produced by mkimapdcert look to be valid? 

Just some thoughts, again, not a courier guy, so I'm flying a bit blind.

----------

## vespaman

Yes, I used s_client again.

But i think i have found a solution that works somewhat; adding useflag gnutls and re-emerging! So I am  :Very Happy: 

Not sure why this fixed things. But this gives me another error in the logfile;

```
May 19 19:20:42 oxygen imapd-ssl: *** glibc detected *** /usr/sbin/couriertls: malloc(): memory corruption: 0x093c5a28 ***
```

When this happens the mail client just stalls for a while.

.. so I guess it is not the perfect solution. 

I am seriously thinking about ditching courier now, after 10 years of faithful service.   :Confused:   Dovcecot looks like an alternative..

Any way, thank you for your help, at least it is somewhat running now!

 Micael

----------

## cach0rr0

could be courier was built against an older version of openssl, openssl was upgraded, courier needs to be rebuilt against newer openssl? 

i say that as that could be why using gnutls got past the issue. if so, revdep-rebuild, or simply forcibly re-emerge courier (this time without gnutls use set)

PS: dovecot is damn simple, and it works! Only reason I use cyrus is its mailbox files (no, not mbox) rather than a traditional .maildir setup

----------

