GNOME Bugzilla – Bug 704725
Collection sources don't allow different sending server password
Last modified: 2015-03-16 14:22:20 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=977720 Creating a new account with GMail as a Receiving server, but a different (personal) Sending server, also authenticated, with at least Contacts or Calendar sources being automatically added, results in a password lost on message send. Basically, if at the end of the wizard user selects to add either Google Contacts or Calendar, then the main source is setup as a Collection, which doesn't allow different passwords for the sending part. That means that the user is asked for the GMail password on start and when sending then for a password for the Sending server. After the send, closing evolution and running it again results in a password prompt for the GMail (Receiving part). This repeats after each message send. Leaving both checks at the end of the wizard unchecked creates standalone sources, which don't suffer of this.
Here's a link for the related comment in the sources: https://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-source-registry.c?h=gnome-3-8#n1907
It seems to me that the only option is to change e-mail-config-google-summary.c and e-mail-config-yahoo-summary.c and set 'none' backend name for the [Collection] when the Sending and Receiving servers differ (not counting sendmail), because getting to actual host address at ESourceRegistry is impossible (it requires knowledge of the respective backends). This is still not ideal, neither the described SharedPassword idea, because the user will re-type the password for Calendar/Contacts sources in this case, instead of reusing the same password for Receive/Calendar/Contacts sources and only a different password for the Send part. (Also remember two-factor authentication and application-generated passwords for Google accounts.)
The transport source should be parent-less in this scenario, not part of the collection. But we don't have a graphical way to manage that at the moment; the transport source would not be deleted along with the collection. (Not that it would do much harm, really. It would just be a key file left behind.) This ties into adding a UI to support multiple mail identities, which would list identity and transport sources separately from accounts. I still mean to get to that sometime soon.
This is fixed in 3.16.0, I'm closing it as such.