Bug 468795 - Drops back on non-encrypted IMAP when if TLS or SSL encryption is selected
Drops back on non-encrypted IMAP when if TLS or SSL encryption is selected
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-10-27 21:48 EDT by Henrik Nordström
Modified: 2009-11-18 05:30 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-18 05:22:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Henrik Nordström 2008-10-27 21:48:12 EDT
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):


How reproducible:


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.
Comment 1 Milan Crha 2008-11-06 05:35:03 EST
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: 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.
Comment 2 Bojan Smojver 2008-11-22 17:15:43 EST
Seeing the same with evolution-
Comment 3 Bojan Smojver 2008-11-22 20:20:38 EST
BTW, recreation of the account in Preferences does not help with the problem here. Still uses IMAP instead of IMAPS (verified with netstat).
Comment 4 Henrik Nordström 2008-11-25 08:00:14 EST
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):

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.

Comment 5 Bug Zapper 2008-11-25 23:20:46 EST
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:
Comment 6 Henrik Nordström 2008-12-07 17:15:03 EST
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.
Comment 7 Bug Zapper 2009-11-18 03:40:28 EST
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: 
Comment 8 Henrik Nordström 2009-11-18 04:46:18 EST
Seems to work fine in F12.
Comment 9 Milan Crha 2009-11-18 05:22:30 EST
Thanks for the update, I'm closing then, but please reopen, if it happens again.
Comment 10 Bojan Smojver 2009-11-18 05:30:53 EST
(In reply to comment #8)
> Seems to work fine in F12.  


Note You need to log in before you can comment on or make changes to this bug.