GNOME Bugzilla – Bug 747988
Adding 000D characters in plaintext mail replies
Last modified: 2015-05-25 10:18:46 UTC
Created attachment 301724 [details] message before reply, looks normal On some messages (I have not been able to determine a pattern) pressing reply results in line ends including "null" characters. The sort of thing that looks like a box with the unicode codepoint in them, four zeros in a box. Attached is a screenshot of an email, then after pressing reply, which shows the brokenness. Version is 3.12.11
Created attachment 301725 [details] message after reply, broken characters on line endings
*** Bug 748168 has been marked as a duplicate of this bug. ***
Thanks for a bug report. An example message would be very helpful, to test whether it can still be reproduced in the current stable version of evolution, which is 3.16.1 right now.
How best to export a single message? Can they be exported "privately" ? I don't mind my own email, but the easiest samples I can find involve other people's mail addresses that shouldn't be online.
Right-click the message in the message list and choose "Save as mbox", then edit the file and replace each private string (each letter in the private string) with an 'x' character - or any similar. I hope the save will not fix the new line breaks in the message content.
The problem is that all message I currently have with this, have their content base64 encoded. Editing that is not exactly fun (also they all contain private information).
Created attachment 302011 [details] exported failing message as mbox
Thanks for the message. Do you see the issue when you import it into evolution and try the Reply on it? I do not, from which I guess the export or the import "normalized" the message content in some way which fixed it. I tried to compose a simple HTML message in an Outlook 2007 and send it myself. Then I enabled "Only ever show plain" in the Preferences, and then selected the message and replied to it. I do not see the extra lines, neither any 000D square there, using Evolution 3.16.1 (actually git master, but that's the same with 3.16.1 in this regard, both are using WebKit-based message composer, instead of the GtkHTML composer from 3.12.x).
No, I do not see the issue when replying to the message after reimporting the mbox. Note, I don't see this with all mails, even from the same outlook users. Some will have this bug, some won't. I haven't found any common thread yet.
I see. The import (or even the export) could change the message structure, like normalizing new line characters and such. Please try to find the message on the disk, the one with which you can reproduce the issue. To find it on the disk, check the Message-ID header in the message source (Ctrl+U) and search for it in one of the folders: ~/.local/share/evolution/mail ~/.cache/evolution/mail The first is when you've it stored under On This Computer, the later when you connect to a remote server to get the message, using either IMAP or EWS. The message-id value can be found multiple times, once probably within folders.db file, which is not what you would search for, then in text files. If there exists any replies to the message, then there can these replies reference this message by its ID too, thus you might figure out which exact message it is by examining its content. Getting this raw message content might help to get exactly the same version as you have. One more caveat could be the editor you'd use for sanitizing the output. It should not break the line breaks. Feel free to send the message only to me, I promise to use it for testing purposes only and will not share it anywhere else. Just name the bug report in the subject, thus I'd not overlook it in my spam folder and better to pack (zip or xz) the message and add it as an attachment, to make sure that no transport would modify the new line breaks.
Thanks Karl, I received your mail. The main difference is that the body of the message is encoded in base64, with compare of the imported/exported message, which is basically not encoded. The base64 part contains standard CRLF markers, which feels interesting. In any case, I can reproduce the issue with your message in 3.12.11 of Evolution, but not with the current stable 3.16.1 (git master, to be precise, but that might be pretty much the same as the 3.16.1 in this regard), where is used a WebKit-based composer, instead of the old GtkHTML-based. Due to that I'm closing this in favor of the current stable 3.16.x version. Thank you all for the help with the investigation of this. I appreciate it.
I just realized, when looking on some other bug report, that the problem is not with GtkHTML, apart of it showing encoded 000D characters (encoded as " "), but that those encoded characters shouldn't be in the HTML code at all. The fix is in the evolution-data-server, thus I move this there. A minimal reproducer is: $ mailto:?subject=subject.\&body=text.%0D%0A%2a%2a%29%20text2%0d%0a Created commit f0c6d0a in eds master (3.17.3+) Created commit 6acb9be in eds gnome-3-16 (3.16.3+)