GNOME Bugzilla – Bug 749292
SMTP connection lost while reading message data
Last modified: 2015-06-02 04:48:47 UTC
Dear Milan et al., unfortunately, I have to file a bug report today that I don't have the slightest idea about and that is probably unreproducible on your side as well. I don't know exactly when this symptom occurred the first time, because it requires some special boundary conditions. The symptom is that e-mails sent from Evolution are sometimes silently dropped, that is they do never reach their destination and Evolution has no idea about this fact! However, whenever this happens, the following line is printed in the SMTP server's (exim4 4.80-7+deb7u1) log files: SMTP connection from (HOST) [IP] lost while reading message data (HEADER) Now comes the interesting part: - I receive mails without a flaw. - This only happens when sending mails with attachments of a certain size (reproducible with as less as ~150kB). - This never happens when sending mails with Icedove/Thunderbird from the same computer. - This never happens when sending mails over a different SMTP server (Postfix in this case). - This never happens for any other colleague sending from either Outlook, Apple Mail or Thunderbird/Windows over the same SMTP server. Do you have an idea what that could be? Is there any way to put Evolution in some kind of debug mode so that it prints some verbose messages? This is all with evolution 3.12.9~git20141130.241663-1+b1 evolution-data-server 3.12.9~git20141128.5242b0-2+deb8u2 from Debian. If there is anything else that I can do or any additional information that you need, please don't hesitate to ask! Cheers, Fabian
Thanks for a bug report. I would start with running evolution as this: $ CAMEL_DEBUG=smtp evolution and watch what is shown there. Your version contains a timeout setting to 90 seconds for connections, which means if the other side doesn't respond with anything within those 90 seconds, then the connection is considered closed. Similar bug #747342 mentioned use of an SSH tunnel. Is that the case for you too?
*** Bug 749571 has been marked as a duplicate of this bug. ***
*** Bug 749730 has been marked as a duplicate of this bug. ***
I made some investigation in this and I was not able to reproduce exactly this. I even cheated about set timeouts on the connection. When the Evolution's SMTP code failed, then it reported it in the UI. The failure message was "Socket I/O timed out". In any case, I'm pretty sure the problem is due to the set timeout on the connection, thus I made some changes in the evolution-data-server to set higher timeout. I chose an artificial value computed based on the message size, expecting the upload speed to not be slower than 512 bytes per second. I'd appreciate if you could give a try to the change too. If it'll work, then I would release also an evolution-data-server 3.12 with the fix included. Created commit 6983511 in eds master (3.17.3+) Created commit 3822efe in eds gnome-3-16 (3.16.3+)
*** Bug 747342 has been marked as a duplicate of this bug. ***
Dear Milan, I have rebuilt e-d-s with your patch and the problem persists. I am not using a SSH tunnel and the problem is most probably not time-out related, as (1) I am on the same network as the SMTP server, (2) the log message on the server side appears nearly instantly and (3) myself and other colleagues can successfully send mails with huge attachments with other MUAs. I'll see what insight the CAMEL_DEBUG option brings. Thank you for your effort! - Fabian
> I'll see what insight the CAMEL_DEBUG option brings. This happens after clicking the "Send" button: [SMTP] Connecting to server gate.ghi.rwth-aachen.de:25 from account 1380744122.1991.1@kff50 [SMTP] received: 220 gate.ghi.rwth-aachen.de ESMTP Exim 4.80 Wed, 27 May 2015 11:27:28 +0200 [SMTP] sending: EHLO kff50.ghi.rwth-aachen.de [SMTP] received: 250-gate.ghi.rwth-aachen.de Hello kff50.ghi.rwth-aachen.de [137.226.11.50] [SMTP] received: 250-SIZE 52428800 [SMTP] received: 250-8BITMIME [SMTP] received: 250-PIPELINING [SMTP] received: 250 HELP [SMTP] Sending with server gate.ghi.rwth-aachen.de:25 from account 1380744122.1991.1@kff50 [SMTP] sending: MAIL FROM:<greffrath@ghi.rwth-aachen.de> [SMTP] received: 250 OK [SMTP] sending: RCPT TO:<prieler@ghi.rwth-aachen.de> [SMTP] received: 250 Accepted [SMTP] sending: DATA [SMTP] received: 354 Enter message, ending with "." on a line by itself (evolution:2984): camel-WARNING **: CamelStreamFilter::write() reported failure without setting its GError (evolution:2984): camel-WARNING **: CamelDataWrapper::write_to_stream_sync() reported failure without setting its GError (evolution:2984): camel-WARNING **: CamelMimePart::write_to_stream_sync() reported failure without setting its GError (evolution:2984): camel-WARNING **: CamelMultipart::write_to_stream_sync() reported failure without setting its GError (evolution:2984): camel-WARNING **: CamelMimeMessage::write_to_stream_sync() reported failure without setting its GError (evolution:2984): camel-WARNING **: CamelSmtpTransport::send_to_sync() reported failure without setting its GError (process:3089): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
Sorry, the last line belongs to the iceweasel process, not evolution.
> I chose an artificial value computed based on the message size, expecting the upload speed to not be slower than 512 bytes per second. This will raise the time-out to more than half an hour for a 1MB message. Is this intended?
(In reply to Fabian Greffrath from comment #7) > (evolution:2984): camel-WARNING **: CamelStreamFilter::write() reported > failure without setting its GError Here we go, that's the reason. The question is why the write() call failed. It can be one of the filters failing for some odd reason. I'll try to dig in the code. (In reply to Fabian Greffrath from comment #9) > This will raise the time-out to more than half an hour for a 1MB message. Is > this intended? There was used none timeout at all in the past, thus this is still better than before.
(In reply to Milan Crha from comment #10) > Here we go, that's the reason. The question is why the write() call failed. > It can be one of the filters failing for some odd reason. I'll try to dig in > the code. This had been reported downstream at [1] and is fixed for 3.16.0 with commit [2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1186815 [2] https://git.gnome.org/browse/evolution-data-server/commit/?id=bae0c64
Milan, I have rebuilt e-d-s 3.12 locally with your patch applied and it works! \o/ Please, this has to go into a 3.12.x point release.
(In reply to Fabian Greffrath from comment #12) > Please, this has to go into a 3.12.x point release. I know it's annoying, but 3.12.x is dead. The latest 3.12.x release is 3.12.11, but there are still distributions which ship 3.12.9 (the 3.12.11 was released on 2015-02-09).
Debian is one of these distributions. When 3.12.11 was released in Feb, Jessy was already long frozen. I have seen, though, that there is still some activity on the 3.12 branch in GIT. Even if it will not get officially released anymore, maybe some of the patches that fix really severe bugs (like this one) could get dropped there, so it will be easier to prepare package updates for stable distro point releases.
The only activity there are translations. Some translators didn't notice that there will not be more releases. The most recent one, "Updated Occitan translation", was a clear mistake, which applied probably the same change into all "known" branches, including for example gnome-2-32, which is a nonsense and could actually break the translation there, instead of fix, because it could remove in-2.32-still-being-used translated strings, which are not part of 3.16.x. [1] https://git.gnome.org/browse/evolution-data-server/log/?h=evolution-data-server-3-12
*** Bug 749618 has been marked as a duplicate of this bug. ***