Description of problem: Seems impossible to get Evolution to use SSL or TLS encrypted IMAP. It starts by using the encrypted connection finding the folderrs, but as soon as you try accessing a folder it drops down to plain-text IMAP communication. Tested both with TLS and SSL. And with the server port hardcoded in SSL mode. (it still fell back on port 143...) Version-Release number of selected component (if applicable): evolution-2.24.1-2.fc10.x86_64 How reproducible: always Steps to Reproduce: 1. Configure an IMAP server with TLS or SSL 2. monitor the traffic with wireshark 3. try reading email and watch the traffic in wireshark Actual results: Silent dropdown to unencrypted IMAP. Lots of unencrypted message exchanges seen in wireshark, including but not limited to acutal mail messages. Expected results: That the connection stays encrypted, except for the initial STARTTLS when TLS is selected. Or if it fails on agreeing on the encryption with the server then disconnection and an error message. Additional info: My server is using a self-signed certificate, and runs a quite old IMAP software (IMAP4rev1 2001.315rh). I suspect there may be something with the SSL/TLS encryption the two do not agree on.
I tried this with some newer dovecot server and everything seems to work fine. Try to set the TLS in your account, close Evolution and run this command: $ CAMEL_DEBUG=all evolution >& evo.log connect to the server, view one message and close evolution. Then open file evo.log and search for "tls" in it, there should be lines like: received: * OK Dovecot ready. (other server here, probably) sending : A00000 CAPABILITY received: * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS QUOTA STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5 received: A00000 OK Capability completed. sending : A00001 STARTTLS received: A00001 OK Begin TLS negotiation now. sending : A00002 CAPABILITY ... When I look in wireshark, everything comes in SSL now on. I'm not sure, but it seems the changes in the account setup are taking effect after next start of Evolution, did you restart Evolution after turning on/off TLS/SSL? You wrote that some data came encrypted, thus I guess you did, so just mentioning it. Note: The log contains many information, could even passwords. I do not require it here, but if you consider it'll be better to put here all the log, please strip passwords or other confidential data from it.
Seeing the same with evolution-2.24.1.1-1.fc10.i386.
BTW, recreation of the account in Preferences does not help with the problem here. Still uses IMAP instead of IMAPS (verified with netstat).
Sorry for the delay. Ran the debug trace today, and it looks a bit confused. It's fine up to the CAPABILITY point, but then follows a sequence like the following (after lots of mbox:/home/henrik/.evolition/mail/... accesses): sending: A00003 AUTHENTICATE CRAM-MD5 received: * XXXXXXX received: * OK [CAPABILITY ........ and the rest of the server hello] sending : C00001 CAPABILITY received: * CAPABILITY [list of capabilities] received: A00003 OK [CAPABILITY ... ] User Henrik authenticated sending : A00004 NAMESPACE received: * (list of namespaces] received: A00004 OK NAMESPACE completed CamelException.setc((nil), 303, 'Unexpected OK response from IMAP server: A00003 OK [CAPABILITY ....] User henrik authenticated') then it continues with C00xx commands, logging in, indexing the mailboxes etc. The C00xx commands is all seen in plain-text using wireshark. There is also additional A00XX commands, which all seem to be over the TLS connection. Regards Henrik
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I can set up a test account on my imap server if you need a server to test against. It supports both STARTTLS and imaps.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Seems to work fine in F12.
Thanks for the update, I'm closing then, but please reopen, if it happens again.
(In reply to comment #8) > Seems to work fine in F12. Ditto.