Description of problem: Configuring Evolution to use SMTP with SSL for sending e-mail completely hangs under Mate 1.5.8 after composing an e-mail and pressing the Send/Receive button. There is no acknowledgement that Evolution is even making a remote connection. It appears to still be a keyring/dbus issue. I believe this is a critical bug -- I cannot use Gnome 3 since I have a tri-monitor setup on my server, making MATE the only viable desktop environment available to me, and I have used Evolution as my e-mail client for 10 years now. I understand that MATE is a fork of Gnome, so things are starting to diverge, but I believe it is vital that major pieces of software are not broken under MATE. I am at the mercy of web e-mail until this issue gets fixed. Version-Release number of selected component (if applicable): evolution-3.6.4-3.fc18.x86_64 mate-keyring-1.5.1-2.fc18.x86_64 mate-keyring-pam-1.5.1-2.fc18.x86_64 How reproducible: Always Steps to Reproduce: 1. Login to MATE 1.5.8 2. Configure Evolution to use SMTP with SSL for sending e-mail. 3. Compose a test e-mail. 3. Press the send/receive button. 4. Watch evolution hang. Actual results: Evolution hangs while saying "Sending message". Expected results: Evolution makes an SSL connection to the SMTP server and sends the e-mail. Additional info: Steps I've already tried (nothing has worked): 1. Disabled/enabled Gnome and/or MATE keyrings. 2. Disabled 4 autostart mate keyrings and removed mate-keyring. 3. Logged into Gnome 3 on my laptop and updated gnome-keyring passwords. Logged out of Gnome and back into MATE to test results. 4. Removed unofficial repo and installed official mate packages from Fedora. 5. Installed mate-keyring-1.5.1-2.fc18 from Fedora testing.
Additional Info x2: This problem occurred after I changed my SMTP login password on the remote e-mail server (forced password change every 6 months), leading me to believe that it is a keyring/dbus/pam problem in MATE. Tried some additional debugging on my laptop, opposed to my server: Evolution can send e-mail in Gnome 3 via SMTP on the laptop. Evolution cannot send e-mail in MATE via SMTP from the same laptop. Why was the SMTP password configuration option removed from Evolution under File -> Preferences -> Mail Accounts -> Sending Email? It is ludicrous that you can no longer tell Evolution to *not* remember the authentication password to get around this problem manually.
Finally tracked down the source of the problem. The Gnome PolicyKit was being launched at startup, as well as the Gnome Settings Daemon. It appears that one/both launched different versions of gnome-settings-daemon (one was daemonized, one was not), which severely confused Evolution in MATE. It had nothing to do with keeping mate-keyring-daemon from running. The following steps fix the problem: 1. Disable Gnome PolicyKit and Gnome Settings Daemon from being launched at startup. 2. Allow MATE PolicyKit and MATE Settings Daemon to be launched at startup. 3. Kill all keyring daemons 4. Log out. 5. Log in. After logging backing in, only a single, daemonized version of gnome-keyring-daemon now runs, as well as mate-keyring-daemon: $ ps aux |grep keyring kriehn 1868 0.0 0.0 617424 3684 ? Sl 00:28 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login kriehn 2053 0.0 0.2 532832 10480 ? SLl 00:28 0:00 /usr/bin/mate-keyring-daemon --start --components=secrets With the updated version of mate-keyring installed and running (mate-keyring-1.5.1-2.fc18.x86_64 and mate-keyring-pam-1.5.1-2.fc18.x86_64), and only the daemonized version of gnome-keyring-daemon running in MATE, Evolution finally realized there was a change in the SMTP password and allowed me to update it. I could reclaim 12 hours of my life if Evolution had not removed the option to (not) save the SMTP password within the Authentication preferences. I'm closing this bug, but it seems like it should remain open based upon Gnome developers continuing to remove useful configuration and debugging options within Gnome applications.
Thanks for a bug report and all the investigation around it. I would not even think of this solution. I only want to clarify one thing (or rather add my hypothesis): It doesn't matter if you save or not the password, I'm afraid the bigger problem was that the password prompt was not shown for some reason. You might see evolution in an authentication request, and the evolution-source-registry, which does the password prompts and all the things around passwords, in some stuck or failed way, due to stuck keyring. That you fixed keyring made the source registry process communicate with it properly again.
I am reopening this bug -- the problem only corrected itself on the laptop because I could log into Gnome 3 first to update the password. On my server, in which logging into Gnome 3 is not an option, the problem persists. Additional issues: gnome-keyring-daemon looks in ~/.local/share/keyrings mate-keyring-daemon looks in ~/.config/mate/keyrings Evolution appears to refuse to look at either keyring, regardless of whether I force gnome-keyring-daemon or mate-keyring-daemon (or both) to run. And you are right -- for the life of me I cannot get evolution display the password prompt. I am at a loss as to how to fix this.
Hrm, OK, I think the changes in the running daemons will work only after the evolution-source-registry is restarted, because that process does all the password management through gcr library. The password prompts are done through gcr-prompter (usually located at /usr/libexec), but if the evolution-source-registry is already stuck in a "never ending password prompt", then the next prompt for the same source is just piled into a queue. Please try to run gnome-keyring-daemon only, and then kill evolution-source-registry. After that kill also all other running evolution processes (possibly evolution-alarm-notify, evolution-calendar-factory), because these are also connected to the evolution-source-registry and its restart may confuse them.
After a fresh login: $ ps -A |grep keyring 871 ? 00:00:00 gnome-keyring-d $ ps -A |grep evolution $ So, only gnome-keyring-daemon is running, and all evolution processes are stopped. $ evolution java version "1.7.0_17" OpenJDK Runtime Environment (fedora-2.3.8.3.fc18-x86_64) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) After launching evolution, I can receive pop e-mails, but still cannot send via smtp. It still hangs at "Sending message". I then removed all keyrings from ~/.local/share/keyrings to start over, and for a while I could not receive pop e-mails either. So I used seahorse and manually opened the keyring, which was locked. This allowed evolution to prompt for the pop login password, which was then stored as an "Evolution Data Source" password. I then examined it and verified that it was the pop password being stored. By all means, I should expect to receive another prompt after trying to send an e-mail, and see the keyring get updated with another "Evolution Data Source" that stores the smtp password. No such luck.
As an additional attempt, I found that the mail transport key file is stored in ~/.config/evolution/sources. I examined the key file related to my SMTP login, and used its identity to manually try and create a new stored password in the same keyfile the pop password is stored in via seahorse. I used the identical format as the pop password, but with the appropriate SMTP UID found in ~/.config/evolution/sources. It isn't recognized since the password is stored as a "Stored note" instead of "Password or secret", and there is no "e-source-uid" under the details section of the password. A failed hack, but it was an attempt to try to get evolution to resolve the password nonetheless.
If the password prompt works for POP, then it should work for SMTP as well. Could you install debuginfo packages for evolution and evolution-data-server, then try to send a message, and while the composer shows "Sending message" get a backtrace of running evolution with a gdb command like this: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt please? The backtrace can show your email addresses, server names and even passwords, it depends in which state the application is, thus please check for them before attaching it here (I usually search for "pass" (quotes for clarity only)). In any case, we'll see where evolution is stuck. I suspect that it's waiting on a server response, but it doesn't come back, which can be due to using different port than the server expects. You may check this in account properties, same as whether you've set proper Authentication method.
Just in case, the password prompt issue can be related to bug #953641, see that bug for more details.
Created attachment 737389 [details] Evolution backtrace when trying to send e-mail via SMTP $ rpm -q evolution-debuginfo evolution-data-server-debuginfo evolution-debuginfo-3.6.4-3.fc18.x86_64 evolution-data-server-debuginfo-3.6.4-2.fc18.x86_64 $ evolution & java version "1.7.0_19" OpenJDK Runtime Environment (fedora-2.3.9.1.fc18-x86_64) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) $ ps -A |grep evolution 24190 ? 00:00:00 evolution-sourc 24202 ? 00:00:00 evolution-calen 24424 ? 00:00:00 evolution-addre 27000 pts/2 00:00:02 evolution 27006 pts/2 00:00:00 evolution-alarm At this point I compose a test e-mail to myself and hit send. Evolution hangs at "Sending message". $ gdb --batch --ex "t a a bt" -pid=27000 &>bt.txt $ I checked the file for e-mail addresses, passwords, etc. None found. Backtrace contains references to smtp. I have the proper authentication -- before having to update the SMTP password on the e-mail server, evolution worked fine. SSL encryption on port 465 is being used with the proper hostname, the supported types allow for login authentication, the proper username is being used, etc. The settings are the *same* as my laptop, which auto-magically fixed itself after stopping and restarting the keyring daemon(s) up-teen times.
$ rpm -q gcr gcr-3.6.2-3.fc18.x86_64 $ Downgraded gcr and gcr-devel via yum. $ rpm -q gcr-3.6.2-1.fc18.x86_64 $ I then ran evolution and composed a test e-mail. After hitting send, evolution prompted me for the new SMTP password, and sent it. Looks like bug #953641 is the real culprit! Thank you for helping me debug this! G
Thanks for the backtrace. The SMTP shows a waiting password prompt, as (partly) expected. Good the downgrade works for you too. I'm marking this as a duplicate of the gcr bug. *** This bug has been marked as a duplicate of bug 953641 ***