GNOME Bugzilla – Bug 761096
[IMAPx] Disable message multi-fetch by default
Last modified: 2017-04-03 09:40:22 UTC
I am using evolution with multiple IMAP+ accounts. This problem occurs with my gmail account only. In some cases, emails with attachments are corrupted. If the error occurs, it behaves as follows. In the list of e-mails, the e-mail is shown with - correct sender, - correct subject - correct date - but the attachment icon is missing. If i select the e-mail, it takes a bit longer than usual (approximately 3 seconds) until the e-mail is displayed. In the header area of the displayed mail, where i should see From,To,Subject,Date,number of attachments and save-all button, is completely empty. In the section where i should see the mail text and the attachments at the bottom, there is no mail text, but some part of the source code which looks like the un-decoded attachment. For example, i expect to see this (this is the german locale): [Header area] Von: My Name <myadress@googlemail.com> An: myadress@googlemail.com Betreff: The subject of the e-mail Datum: Mon, 25 Jan 2016 17:49:35 +0100 [Mail content area] Von meinem Samsung Galaxy Smartphone gesendet. JPEG-Bild-Anlage (20160125_172458_resized_2.jpg) JPEG-Bild-Anlage (20160125_165921_resized_2.jpg) [end] Instead, it looks like this: [Header area] [Mail content area] ----_com.android.email_668909055510910 Content-Type: image/jpeg; name="20160125_165921_resized.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="20160125_165921_resized.jpg"; size=512891 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAIBAQEBAQIBAQECAgICAgQDAgICAgUEBAMEBgUGBgYF BgYGBwkIBgcJBwYGCAsICQoKCgoKBggLDAsKDAkKCgr/2wBDAQICAgICAgUDAwUKBwYHCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgr/wAARCAZgA5YDASIA [and many further similar lines] [end] Opening the source code of the e-mail shows this: ----_com.android.email_668909055510910 Content-Type: image/jpeg; name="20160125_165921_resized.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="20160125_165921_resized.jpg"; size=512891 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAIBAQEBAQIBAQECAgICAgQDAgICAgUEBAMEBgUGBgYF BgYGBwkIBgcJBwYGCAsICQoKCgoKBggLDAsKDAkKCgr/2wBDAQICAgICAgUDAwUKBwYHCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgr/wAARCAZgA5YDASIA [many further similar lines] 3fUv2Rfh1q4WSadm2DALJg9/7uM/jRXl2kf8FFfgPNZ+bdeNrQKxyrNMCSfcZorkeW5VJ3cEaqWL Ssmz /9k= ----_com.android.email_668909055510910-- I cannot tell when exactly this problem occurs. It only happens with e-mails with attachments, but sending the same e-mail a second time often works. It is independent of the sender of the e-mail. In the web interface as well as on my mobile phone the e-mail is displayed correctly. If i can help with any further information, please let me know.
Thanks for a bug report. There is some problem when downloading large messages from the GMail server. Such large messages are downloaded in smaller chunks, which can break in certain situation(s). I do not know the cause yet, though. There had bee filled a similar downstream bug report too: https://bugzilla.redhat.com/show_bug.cgi?id=1306846 A broken message deletion from ~/.cache/evolution/mail/<gmail-account-uid>/folders/.... will cause re-download of the message, which can eventually be downloaded properly (like when you requested a re-send from the sender). It can be also a problem with IDLE implementation in pre-3.18.5 of the evolution-data-server. I suggest to update to it once it is available in your distribution (it had been released only yesterday). You can also try to disable "listen for server change notifications" in the account Properties->Receiving Options tab, but you lose functionality, which is not always desired. As I noted in the downstream bug report, I added [1] an option for the IMAPx accounts named "use-multi-fetch", which defaults to 'true' (current behaviour). Set it to 'false' to disable message download in chunks. You can do that by: a) locate correct .source file eithe rin ~/.config/evolution/sources or ~/.cache/evolution/sources/ which references the right server and contains section [Imapx Backend]. Locate in this section key named UseMultiFetch or add a new one in that section, if not there yet, with value 'false', thus it'll look like: UseMultiFetch=false b) restart evolution, or ideally also other background evolution processes, for example evolution-source-registry (re-login or restart will do it most easily). Since then the messages will be always downloaded in one call, not in chunks. It's not meant to be a fix for this issue, it's just a quick workaround for it. The option is available since 3.19.91+ of the evolution-data-server. [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=6ace0dd
Hi, migrated from Fedora bugzilla. I'd like to note that my 'Listen for server change notifications' has been disabled when this bug occurred. So the IDLE implementation is likely orthogonal to this bug. I'd like to try the 3.19.91+ data-server, but looks like it is only available on for Fedora 24? (koji?) Any chances of backporting? Purging corrupted cached message is a working workaround; but it is difficult to tell the message ID from the Evolution UI. Is there a known trick to find this out easily?
(In reply to rainwoodman from comment #2) > I'd like to note that my 'Listen for server change notifications' has been > disabled when this bug occurred. So the IDLE implementation is likely > orthogonal to this bug. Thanks for the point. Good to know that the IDLE implementation in IMAPx isn't the part of the issue. > I'd like to try the 3.19.91+ data-server, but looks like it is only > available on for Fedora 24? (koji?) Any chances of backporting? Right, it's a development version. I backported that change and created a scratch build in koji, which will disappear in about a week. You can download it from the below URL, just click the architecture you use and then, at the bottom of the page, will be created packages. http://koji.fedoraproject.org/koji/taskinfo?taskID=13020002 > Is there a known trick to find this out easily? Those message UIDs are shown only when the messages are loading, the info-message 'Retrieving message 'NNNNN'", where the NNNNN is the UID, but once the message is downloaded this info-message only flashes in the UI. I suggest to check the message source (Ctrl+U) and pick from there some text which looks unique, then search for that text (in files) in the IMAPx cache.
Thanks. I will test it once I get to my office computer (likely tomorrow). I filed a feature request regarding displaying message ID in a more permanent way.
*** Bug 761554 has been marked as a duplicate of this bug. ***
Update: After setting up the UseMultiFetch=false flag with the scratch build, I have not yet seen a broken messages. So MultiFetch is the place where the bug is.
(In reply to rainwoodman from comment #6) > After setting up the UseMultiFetch=false flag with the scratch build, > I have not yet seen a broken messages. Thanks for the update. Out of curiosity, did it strike that often for you? I'm thinking to revert the option value, make it 'false' by default. The way IMAPx currently works is different than it used to be when the multifetch was a benefit. IMAPx currently bets on concurrent connections, instead of interleaving commands.
At the peak, I used to receive more than two broken emails per day. I typically usually leave evolution running for days or months, a freshly launched Evolution seems to be less likely to invoke this, but these are just impressions, there is no solid numbers to back this. But I now recalled it could just be I haven't been receiving large emails recently, because I didn't recieve any corrupted emails on my F22 laptop after the update on F23 neither. Thus I need to retract my comment 6. We'd better wait a few more days till the bug comes back to F22(which didn't receive this update) to rule out other systematic effects ...
*** Bug 763280 has been marked as a duplicate of this bug. ***
I'm thinking of changing the default value of the UseMultiFetch to FALSE, thus the messages will be downloaded in one go, instead of in chunks. It won't influence users which has already saved the value in the files, only newly created accounts. I would do this by the end of this week, to push the change for the 3.20.0 release, but I'd like to know from you first, whether you've any interesting findings, either positive or negative, from your testing.
Here is an update. Since the last communication: Without setting to False, I saw two broken messages. With setting to True, zero. So disabling multi-fetch definitely helped.
(In reply to rainwoodman from comment #11) > Without setting to False, I saw two broken messages. > With setting to True, zero. Thanks for the update and testing. The above is confusing to me, but I think it means the later is a typo and the 'True' was supposed to be 'False'. Created commit f8b9f68 in eds master (3.19.92+)
*** Bug 765809 has been marked as a duplicate of this bug. ***
*** Bug 766866 has been marked as a duplicate of this bug. ***
*** Bug 771692 has been marked as a duplicate of this bug. ***
*** Bug 778788 has been marked as a duplicate of this bug. ***
*** Bug 780791 has been marked as a duplicate of this bug. ***