GNOME Bugzilla – Bug 312777
smtp-send (TLS) problems with Exim4
Last modified: 2006-01-31 08:24:31 UTC
Distribution/Version: Fedora FC4 I don't know where the problem is, bit some since the releases of Evo 2.x I started to get problems when sending some messages to my debian-standard exim-4.50-8 with TLS. I do not get any errors in the eximj log, but Evolution says that Exim did not accept the mail. step to reproduce: 1. send an email to an addressbook contact in the form of foobar <foo@bar.com> actual result: sometimes message is not accepted reproducable: seldom, but more often the same addressbook entries. ways to circumvent: rewrite address to "foo@bar.com" (so delete the "<>" and the name) Maybe somebody could find out if this is a server problem or an evolution error? It is annoying if one wants to send an email quick. I also think than newer addressbook entries are not effected. If someboy could tell me how to log the full conversation between server an client I will take a look and report back.
if you run evolution with CAMEL_DEBUG=all you can get a log of the server conversation. that should show if what we're sending is correct
hm, strange I sent an email to exactly the same two email-accounts in the "to:" field. all when well, except that i git this messages: " ** (evolution:4221): WARNING **: aspell error: \xb8\xd8~ (evolution:4221): camel-WARNING **: camel_exception_get_id called with NULL parameter. " I hoped that the same error will occur. I will also contact the Exim people. This errors come and go which sometimes is very nasty.
I have also reported this to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321931
Hi, after some time I hand this error again. Does this output help (with tcpdump port ssmtp -vvv -x )? tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 12:43:43.533417 IP (tos 0x0, ttl 55, id 26600, offset 0, flags [DF], length: 60) p548D902D.dip0.t-ipconnect.de.46633 > azimuth.alternativ.net.ssmtp: S [tcp sum ok] 2675929853:2675929853(0) win 5840 <mss 1452,sackOK,timestamp 17044757 0,nop,wscale 2> 0x0000: 4500 003c 67e8 4000 3706 79f2 548d 902d E..<g.@.7.y.T..- 0x0010: d592 a794 b629 01d1 9f7f 72fd 0000 0000 .....)....r..... 0x0020: a002 16d0 eeca 0000 0204 05ac 0402 080a ................ 0x0030: 0104 1515 0000 0000 0103 0302 ............ 12:43:43.533486 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 40) azimuth.alternativ.net.ssmtp > p548D902D.dip0.t-ipconnect.de.46633: R [tcp sum ok] 0:0(0) ack 2675929854 win 0 0x0000: 4500 0028 0000 4000 4006 d8ee d592 a794 E..(..@.@....... 0x0010: 548d 902d 01d1 b629 0000 0000 9f7f 72fe T..-...)......r. 0x0020: 5014 0000 8376 0000 P....v.. 12:43:43.584503 IP (tos 0x0, ttl 55, id 1345, offset 0, flags [DF], length: 60) p548D902D.dip0.t-ipconnect.de.46634 > azimuth.alternativ.net.ssmtp: S [tcp sum ok] 2665680902:2665680902(0) win 5840 <mss 1452,sackOK,timestamp 17044807 0,nop,wscale 2> 0x0000: 4500 003c 0541 4000 3706 dc99 548d 902d E..<.A@.7...T..- 0x0010: d592 a794 b62a 01d1 9ee3 1006 0000 0000 .....*.......... 0x0020: a002 16d0 522b 0000 0204 05ac 0402 080a ....R+.......... 0x0030: 0104 1547 0000 0000 0103 0302 ...G........ 12:43:43.584576 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 40) azimuth.alternativ.net.ssmtp > p548D902D.dip0.t-ipconnect.de.46634: R [tcp sum ok] 0:0(0) ack 2665680903 win 0 0x0000: 4500 0028 0000 4000 4006 d8ee d592 a794 E..(..@.@....... 0x0010: 548d 902d 01d1 b62a 0000 0000 9ee3 1007 T..-...*........ 0x0020: 5014 0000 e708 0000 P.......
unfortunately doesn't help because it's encrypted
I have switched to non-TLS mode for this mail. Then there is no problem. So this must be a problem with TLS? How do we find out?
news information: as I wanted to go back to SSMTP I switched to "always" and then if i choose "check supported typed I again get: (evolution:6363): Gtk-CRITICAL **: gtk_entry_set_text: assertion `text != NULL' failed CamelException.setv(0x9fc6500, 303, 'Could not connect to azimuth.alternativ.net: Connection refused') CamelException.setv(0x9fc6500, 303, 'Could not connect to azimuth.alternativ.net: Connection refused') I do not get it with "never" or with "whenever possible".
when choosing "never" I get: sending : EHLO stevie.marzipan.invalid received: 250-azimuth.alternativ.net Hello p548d902d.dip0.t-ipconnect.de [84.141.144.45] received: 250-SIZE 20971520 received: 250-PIPELINING received: 250-AUTH LOGIN received: 250-STARTTLS This server supports STARTTLS received: 250 HELP sending : QUIT received: 221 azimuth.alternativ.net closing connection
reopening as information has been submitted
This is more of an UI issue. The problem is that the settings are not clear here: In evolution account editor for the secure connection settings: Always = SSL Whenever Possible = TLS So the issue here is that you need to chose Whenever possible as the option for your secure connection, since you server supports TLS. HTH.
(In reply to comment #10) > In evolution account editor for the secure connection settings: > Always = SSL > Whenever Possible = TLS Wow, never have thought that it means THAT! Shouldn't Evolution auto-check if TLS or SSL is available? i think the above settings are almost not related. to what the really mean!? And even if... Evolution should than should give a good error explanation like "your server does not support TLS" or so...
Okie. Agreed. This has been a long pending UI issue. Sigh! not sure when this would be fixed though - i have been pushing this since sometime - and this has been over-shawdowed by a lot of other UI issues. But there is an button "Check for supported Types", clicking that should tell you what the server supports, the ones it does not, is striked off in the combo box. Adnd btw, does this *fix* the issue at hand??
I currently do not have the problem because I have an new server. But I think this should get fixed somehow, anyhow. Thilo
Okie. To exactly find out what your server supports, click the Check for the Supported Types button. That should do the job for you. Am closing this bug for now, since there is a UI bug already filed (i dont remember the exact bug number though, have to ping Andre) regarding the Naming convention used in the Account Editor. Thanks Thilo