Evolution can't connect to my imap ssl server

More info: it doesn't seem like an Evolution problem, but a courier-imapd problem.

I have a home computer running Feisty, and this morning (before I upgraded my work machine to Gutsy) it was able to retrieve mail from the courier-imapd running on the work machine. Nothing has changed on the home computer; it's still running Evo 2.10.1 with the same configuration that used to work.

I'll keep looking at the courier-imapd configuration to see if something I did there is causing Evolution not to be able to connect to it.

Aha! I edited /etc/courier/imapd-ssl and told courier-imapd to use SSLv2:

TLS_PROTOCOL=SSL2

Now everything works! Does Evo not support SSL version 3? There ought to be a better error message when that happens, rather than just saying that the server disconnected with no explanation.

Argh, when I do that, Thunderbird clients can't connect to my imap server because they say the older protocol is unsafe. So I haven't found a solution that works for all clients yet.

Evolution mail supports SSLv3 as well.

I searched a bit and found this report
"Evolution throws error with imap/ssl"
https://bugs.launchpad.net/evolution/+bug/59632

It describes the issue and includes instructions on how to solve the problem.

I hope it helps.

I found that too and I have tried the configuration posted there:

SSLPORT=993
SSLADDRESS=0
SSLPIDFILE=/var/run/courier/imapd-ssl.pid
SSLLOGGEROPTS="-name=imapd-ssl"
IMAPDSSLSTART=YES
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=0
COURIERTLS=/usr/bin/couriertls
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=SSL3
TLS_CERTFILE=/etc/courier/imapd.pem
TLS_VERIFYPEER=NONE
TLS_CACHEFILE=/var/lib/courier/couriersslcache
TLS_CACHESIZE=524288
MAILDIRPATH=Maildir

I restarted /etc/init.d/courier*. Evolution is set to "SSL encryption", and I quit and restarted it. I still get the "Connection reset by peer" error, and the syslog on the server says:

Oct 3 08:34:36 angst imapd-ssl: couriertls: connect: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

I would suggest to use Wireshark (packet analyser) to figure out what is Evolution trying to do.
Wireshark will try to decode part of the initial handshake of the protocol, so you can compare any differences between Evolution and Thunderbird.

In the bug report it mentions that for some changes to take effect, you need to restart the computer. You may have to type from command line "evolution --force-shutdown" to make sure that all evolution processes are terminated.

In addition, you can try to debug the connection from the command line if you set CAMEL_DEBUG=all as described at
http://www.gnome.org/projects/evolution/bugs.shtml
In this case, enable only the IMAPS account.

I hope this helps.

You imported your old evolution config file from evo 2.10.1 to evo 2.12.0, perhaps you should start by backing up and deleting the imported evolution config and restarting evolution. from there enter the connection settings and see if it can connect. If so then it is obviously a change in the way the configuration is written/handled that is incompatible between the two versions. How did you export/import the config file? there is a very specific way in which it should be done.

Alan

Well, I used the same home directory with both evo 2.10.1 and 2.12.0. I tried deleting the ~/.evolution directory, but Evo still remembered my mail accounts. So I went in with gconf-editor and deleted the setting that specified my mail account, and then restarted Evo. What is the correct process for deleting my evolution settings?

Based on the fact that my Evo 2.10.1 at home can't connect to the Gutsy courier-imapd either, I think it's a problem with Courier. Evo will connect if I set Courier to use SSL2, but then Thunderbird can't connect. Evo will not connect with Courier set to SSL3.

In case anyone else is reading this thread, here are some commands I'm finding useful to test ssl connections:

     openssl s_client -ssl3 -connect myhost:993 -state -debug
     openssl s_client -ssl2 -connect myhost:993 -state -debug
     openssl s_client -tls1 -connect myhost:993 -state -debug

to export your profile and accounts do this:

gconftool-2 --shutdown
evolution --force-shutdown
tar cvzf evolution-backup.tar.gz .evolution .gconf/apps/evolution .gnome2_private/Evolution

the copy the evolution-backup.tar.gz to the home directory of whatever other system you want to install the account on and run (on the other box):

gconftool-2 --shutdown
evolution --force-shutdown
tar xvzf evolution-backup.tar.gz

Then restart evolution and ALL your settings will be exactly as they should be and this is a very reliable way to move your evolution accounts and settings from computer to computer.

Alan

This seems to be a problem with courier-imap-ssl. I can reproduce the problem without Evolution using the openssl command-line client:

openssl s_client -connect localhost:993 -state -debug

It is unable to connect to courier-imap-ssl. For comparison, I installed courier-imap-ssl on Feisty, and the same openssl client was able to connect to Feisty's IMAP server. I then copied the files in /etc/courier over to my Gutsy box, restarted the server, and I was not able to connect to the Gutsy server.

This bug looks relevant:
http://qa.mandriva.com/show_bug.cgi?id=26942

Good find. It looks reasonable to be an issue with the environment variables not being passed between these applications.

The Mandriva bug report talks about a patch/fix. It would be interesting to locate it and figure out if the courier-imap project eventually got hold of the fix. In addition, it would be good to update the bug report on Launchpad with info about the Mandriva work.

Could you search for the Mandriva fix source code as described in http://qa.mandriva.com/show_bug.cgi?id=26942

I found this thread on the courier-imap mailing list which confirms my bug:

http://www.nabble.com/TLS-Woes-on-a-New-Installation-of-Courier-imap-4.1.3-t4387642.html

I did some methodical testing (see my post in that thread) and found that Courier 4.1.3 (in Gutsy) behaves quite differently than Courier 4.1.1 (in Feisty). The most recent reply claims that this is fixed in Courier 4.2.0, which has been uploaded to Debian a few days ago. Can we make sure this version is incorporated into the Gutsy release?

Apparently the issue is with the courier package, as shown at
http://packages.debian.org/changelogs/pool/main/c/courier/courier_0.57.0-1/changelog

It is the bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=442271
and the fix is a one-line addition.

To try to get this in Gutsy, you can file a bug report at
https://launchpad.net/ubuntu/+source/courier/
so that courier 0.57 is used.

Otherwise, you may have to create a custom package (recompile). In this case, the following might be of help,
http://simos.info/blog/archives/552

Thanks for the information about how to proceed. It's very helpful.

I filed a bug report against the courier package, and I will recompile a fixed version for my own use in the meantime.

You can tell Courier to use both versions 2 and 3, assuming that Courier is v >= 0.56:

TLS_PROTOCOL=SSL23

(The SSL_PROTOCOL variable, which doesn't seem to be in the Ubuntu configs, can be set the same way.)

Actually this was fixed in Courier 0.57, but we grabbed the patch and added it to our 0.56 packages shortly before the Gutsy release. SSL v2 is seriously antiquated. Using SSL v2 and v3 should be considered a temporary solution. You're better off in the long run to get your clients to use v3 or TLS.