Problem with TLS support

Thanks for your bug. What version of Ubuntu do you use?

I'm using Breezy Badger with last packages. Ask for whatever you need :)

Do you still have that issue?

Yes, it still fails. evolution can start correctly a plain session and a SSL session, but it
can't stablish a TLS session.

You could run evolution with CAMEL_DEBUG=all and attach the output as a file to
this bug - maybe we can get closer to what actually goes wrong.

Created an attachment (id=5638)
Log with CAMEL_DEBUG=all set

I've cut just the "fetching mail" part. If it's needed the full log, I can send
it too

needed info attached

I've forwarded the issue upstream: http://bugzilla.gnome.org/show_bug.cgi?id=336543

What setting do you use exactly for the authentification?

STARTTLS support in evolution seems to be broken;

I just did a capture with evolution talking to a TLS enabled server;

* OK IMAP4 Ready woodchuck 00023754

A00000 CAPABILITY

* CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS

A00000 OK CAPABILITY

A00001 STARTTLS

A00001 OK Begin TLS negotiation now

A00002 LOGIN cs1ajb my-password-in-the-clear

It looks like evolution never bothers to do the TLS negotiation and just starts talking in the clear.

Upstream comment:

I can't reproduce this latest comment... perhaps your SSL libraries don't work?
I have no idea...

how are you getting this "trace"? CAMEL_DEBUG? If so, CAMEL_DEBUG output won't
show that the stream is encrypted because it prints the date before/after
encryption/decryption takes place, so as to actually be useful to us developers
trying to read the protocol log :)

This bug had not been an issue for me in Dapper, but has popped up in Edgy. At issue is a connection to a courier imap server using TLS authentication.

Evolution gives the error: "Failed to connect to IMAP server [server.address] in secure mode: SSL negotiations failed"

On the server side, Courier logs: "couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number".

Courier is running on Debian Stable (Sarge), and is up to date. The IMAP server certificate is of the self-signed lazy "let courier set it up" variety. Thunderbird continues to connect using TLS correctly. Let me know if there's any other info I can provide to help with this!

P.S. As I mentioned above, I had been using the lazy ("localhost") courier cert for TLS authentication. Worth noting that even after switching to a self-signed cert for the correct server address, I have the same issue.

I have similar behaviour with Evolution (Dapper) talking to my Debian server using uw-imapd. In my case plaintext passwords are disabled on the server outside of TLS, and after attempting a STARTTLS command evolution backs off to CRAM-MD5 without encryption.

The notes in the server log:
Oct 24 13:51:48 guinness imapd[31748]: connect from 64.26.x.y (64.26.x.y)
Oct 24 13:51:48 guinness imapd[31748]: imap service init from 64.26.x.y
Oct 24 13:51:48 guinness imapd[31748]: Unable to accept SSL connection, host=ottawa-hs-64-26-x-y.d-ip.magma.ca [64.26.x.y]
Oct 24 13:51:48 guinness imapd[31748]: SSL error status: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Oct 24 13:51:48 guinness imapd[31749]: connect from 64.26.x.y (64.26.x.y)
Oct 24 13:51:48 guinness imapd[31749]: imap service init from 64.26.x.y
Oct 24 13:51:49 guinness imapd[31749]: Authenticated user=myusername host=ottawa-hs-64-26-x-y.d-ip.magma.ca [64.26.x.y]

Andrew: can you follow up to my question?

Forwarded the other comments upstream.

Andrew?

Last comment on the upstream bug:
"...
What I'm saying is that the config pasted does work with "Use Secure
Connection" set to "SSL encryption"."

Can somebody confirm?

We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and don't hesitate to submit bug reports in the future.

Daniel What information are you looking for? The upstream comment doesn't address the issue that I encounter and that Andrew and Dani commented on -- it pertains to SSL, not TLS.