GNOME Bugzilla – Bug 734853
CamelNetworkService fails to connect to 'localhost'
Last modified: 2014-09-04 09:50:22 UTC
using evo 3.13.4, I can't use smtp auth anymore. This used to work (for years) with the same server side setup, it worked at least until 3.13.1, not sure when it started to fail. The situation is: - evo imapx account configured to post using SMTP on a server+port, using authentication, and STARTTLS. The server is localhost:587 which is an ssh tunnel to a remote server. - when I try to check for the supported authentication types, I get none (they are all stroke out) and I can't post either. In the evo log, I see: (evolution:13213): camel-CRITICAL **: network_service_connect_sync: assertion 'connectable != NULL' failed (I even tried CAMEL_DEBUG=smtp and even CAMEL_DEBUG=all to get more data, nada) I get the same assert when I try to post a mail on that account with evo showing a not-very-helpful message: An error occurred while sending. How do you want to proceed? The reported error was "Cannot send message: service not connected.". here is the stack of the assert: Breakpoint 4, g_log (log_domain=log_domain@entry=0x7ffff6de7909 "camel", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff3c2076a "%s: assertion '%s' failed") at /build/buildd/glib2.0-2.40.0/./glib/gmessages.c:1067 1067 in /build/buildd/glib2.0-2.40.0/./glib/gmessages.c (gdb) bt
+ Trace 233960
if I telnet manually on localhost:587, the (remote) server is fine and is correctly reporting tls & auth after the initial EHLO: 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN 250-STARTTLS
If you're using "localhost" as your SMTP server, then I suspect: https://git.gnome.org/browse/evolution-data-server/commit/?id=30ae9231fef6ddf4948294dc63d3c82c5ff719e1
hm, good catch. It's a simple string match. I can then workaround it by using "localhost.localdomain" which is the same thing (on Ubuntu) and indeed, it works. Excellent. I guess the ews "fix" should be reworked somehow. After quickly reading it, it seems it was more a workaround than a fix.
Yeah, I don't know the backstory on that. We'll have to wait for Milan.
FWIW I saw this as well (recent evolution from jhbuild) and using 127.0.0.1 instead of the literal "localhost" worked for me.
I'm not sure why you call the "ews" change a workaround. It doesn't make much sense to try to connect to 'localhost' (when checking whether the host is online or offline), but the problem is that the same 'connectable' is used for actual connection, which is correct to be done (and I missed that part). The other issue is that there is no way to distinguish between user-entered 'localhost' and the default value of 'localhost' for that property. Yes, the default value is 'localhost', instead of an empty string. These are the main obstacles I faced with the design before the "ews" fix.
I chose a different approach now, which works. Thinking of it, connecting to localhost makes sense too, especially when targeting certain port where the service should be listening, thus my initial change was not correct. Created commit b8674dd in eds master (3.13.6+) [1] Created commit f64da6b in eds evolution-data-server-3-12 (3.12.6+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=b8674dd
*** Bug 735652 has been marked as a duplicate of this bug. ***