hmm... if you want to use tls, you can try to explicitly set the port number, e.g. imap.example.com:143

I think it's something related to http://bugzilla.gnome.org/show_bug.cgi?id=339903

With latest evolution (2.6.1) I get this message:
"Error while Fetching Mail.

Failed to connect to POP server pop.mailhost.com in secure mode: SSL negotiations failed"

Then, the problem seems to be on the server or the library which tries to connect with the server. It is a problem that I suffer since one year or two...

BTW, my POP server works OK with TLS in other mail clients.

Another Ubuntu comment: 



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.

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 :)

any news here? still an issue?

I couldn't get an answer from the original reporter, but these comments crept up since then:

"
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]
"

bug #345135 is similar to that one with useful informations too

I'm the original reporter ( hi Daniel :) ), I recently upgraded to Edgy Eft (evolution 2.8.1) and I keep getting the error.

When configuring my account, evolution can't check the server for supported
types. It says:

Error while Checking Service.
Could not connect to POP server pop.warp.es

But evolution has connected to the server and has tried to start a TLS
conversation:

+OK Hello there.
CAPA
+OK Here's what I can do:
STLS
TOP
USER
LOGIN-DELAY 10
PIPELINING
UIDL
IMPLEMENTATION Courier Mail Server
.
STLS
+OK Begin SSL/TLS negotiation now.
.4.................
........d..b.........].e.[`.Da0G.d

And then, it shows the previous error.

When I try to fetch my email, I get this:

Error while Fetching Mail.
Failed to connect to POP server pop.warp.es in secure mode:
TLS negotiations failed

And wireshark shows a connection log similar to the previous one.
What info or traces can I send to this bug to help?

confirming as per duplicates, i'd say

Anyone see any progress? I get no luck changing the STARTTLS option:

katie:/etc/courier# cat imapd-ssl | egrep -v '(#|$^)'
SSLPORT=993
SSLADDRESS=0
SSLPIDFILE=/var/run/courier/imapd-ssl.pid
IMAPDSSLSTART=YES
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=0
COURIERTLS=/usr/bin/couriertls
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=SSL3
TLS_CERTFILE=/etc/certs/secure.linknet.se.pem
TLS_TRUSTCERTS=/etc/certs/UTN.cer
TLS_VERIFYPEER=NONE

This all still gives me the same error, no matter if I choose TLS or SSL in Evolution's server setting, no matter if I enter :143 or :993 in the hostname field.

Nov 25 16:38:14 katie imaplogin: Connection, ip=[::ffff:83.248.131.164]
Nov 25 16:38:14 katie imaplogin: LOGIN: DEBUG: ip=[::ffff:83.248.131.164], command=CAPABILITY
Nov 25 16:38:14 katie imaplogin: LOGIN: DEBUG: ip=[::ffff:83.248.131.164], command=STARTTLS
Nov 25 16:38:14 katie imaplogin: couriertls: accept: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

Oops. I'm terribly sorry, but I got fooled by Evolution's "Check for supported types"-button - I never left/closed the settings window. Next time I fired up evolution it worked. (This ought to be filed as a bug by it self methinks.)
What I'm saying is that the config pasted does work with "Use Secure Connection" set to "SSL encryption".

Does "Use Secure Connection" set to "SSL encryption" work for everybody?

SSL encryption works for me

you guys aren't using the "imap4" (as opposed to "imap") account-type, are you? If you are using "imap4", that would be why... I just noticed this bug in imap4 last night and think I fixed it (I committed a patch but it's untested because I don't have an evo build environment anymore... then again, no one should really be using imap4 anyway since it's not supported)

isn't this one fixed by bug 345135, where TLS was disabled by a wrong HELO sent?

So is this still an issue for anybody or can this be closed as OBSOLETE as per comments 14 and 16?

So is this still an issue for anybody or can this be closed as OBSOLETE as per
comments 14 and 16?

Please feel free to reopen this bug if the problem still occurs with a newer
version of Evolution.