GNOME Bugzilla – Bug 648277
Evolution doesn't used secured IMAP connection after sending a message
Last modified: 2011-09-09 22:10:09 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=697904 Description of problem: I use a imapx account with TLS security. When I send a message, I get this error : [CLIENTBUG] Plaintext authentication disallowed on non-secure (SSL-TLS) connections. My mail server is configured to refuse plaintext login on non secure connection. Evolution is correctly configured to use secure connection (I tried with both TLS and SSL) settings. So after sending a message it seems to ignore this settings when trying to move the message to the sent folder. Version-Release number of selected component (if applicable): evolution-3.0.0-1.fc15 Steps to Reproduce: 1. Use mail server with plaintext login refused on non secure connection 2. Configure imapx account with TLS connection 3. Configure the account to store sent mail on imap server 4. Send mail Actual results: Evolution cannot store the mail in sent folder. Expected results: Mail stored in imap folder using TLS. Additional info: It is also a security risk, because Evolution sends plaintext password though it is configured not to do so.
In fact this is an import settings problem. With Evolution 2.30 my sent folder was set in a folder in the imap account. I tried to change this settings to avoid the problem, and it was set to a local folder (by Evolution tried to stored sent mail in the imap folder ?). Setting it again to the imap folder solves the problem.
Is your SMTP server on the same server as that IMAP server, please? More specificly, is it imap.server.com and smtp.server.com or just one mail.server.com for both? Also, is the SMTP also using SSL (I suppose it is)? Interesting, I would expect just the opposite, that this behaves incorrectly when you have set your Sent folder to an IMAP server folder, and when the IMAP SMTP doesn't have set SSL, but the Receiving options has set SSL.
IMAP and SMTP are on the same server. SMTP is also using SSL or TLS.
(In reply to comment #1) > In fact this is an import settings problem. > > With Evolution 2.30 my sent folder was set in a folder in the imap account. > I tried to change this settings to avoid the problem, and it was set to a local > folder (by Evolution tried to stored sent mail in the imap folder ?). Setting > it again to the imap folder solves the problem. I just now understood the above comment. What you are telling is this: a) have a 2.30.x with an IMAP account which has set Sent folder to an IMAP folder, stored on the server b) IMAP account's Receiving and Sending options are using SSL/TLS c) create a backup from 2.30.x d) install 3.0.x on a clean machine and import backup from c) e) everything looks fine except of sending through this IMAP account, while saving sent message to the Sent folder, evolution is not using SSL/TLS while connecting to the server. f) edit account preferences and set Sent folder to a different folder and then back, with evolution's restart, fixes the issue. Thus, with this all, it seems that the folder linkage structure to the remote server within Sent folder changed between 2.30.x and 3.0.x and it wasn't migrated properly on evolution's start. Did I summarize it correctly?
Yes, except c) and d) which are replaced by : bc) upgrade Evolution from 2.30.x to Evolution 3.0.x.
*** Bug 655088 has been marked as a duplicate of this bug. ***
I just checked and this got fixed around 3.1.2, since commit [1], the part of identifying CamelServices by UID rather than by URL. The thing is that when you select the Draft or Sent folder on a remote server, then the account has stored only folder's URI, without additional parameters of the source, like encryption in our case, thus when Evolution wanted to open such folder it connected to the server again, with "new" setup, without SSL. It does that in 2.30.0 too, as far as I can tell. Using UID instead of URL for CamelService identification avoids this side-effect. http://git.gnome.org/browse/evolution-data-server/commit/?id=e0ac4d79705c
Do you think it'd be possible to backport this commit (or at least just the fix for the nasty bug) for 3.0 and 2.x?
Backporting not possible. These were pretty significant API changes to Camel.
Does this means 2.x and 3.0 will stay insecure? That looks pretty bad.