GNOME Bugzilla – Bug 791475
Incorrectly parses headers in certain case
Last modified: 2018-04-12 16:32:29 UTC
I've a message which is parsed incorrectly and shows raw content (like message source) instead of multipart/mixed and multipart/alternative content. The local copy is saved properly on the disk. After some investigation, the trick is that its main Content-Type header looks like this: Content-Type: multipart/mixed; boundary="----=_Part_1587833_741364485.1510210808363" where there's a space at the end of the first line and a tab at the beginning of the second line, while the second line begins at byte 4096. When I remove the space at the end of the first line or add a space there, then it's read properly. The shown message source (without changes in the file) has missing boundary parameter.
The message parser should check whether headers are folded after reading next chunk from the stream when the previous chunk ended with '\n'. Created commit ee4f5257f in eds master (3.27.4+) Created commit db2650049 in eds gnome-3-26 (3.26.4+)
Err, this change broke evolution-mapi, when parsing PidTagTransportMessageHeaders string, which ends with \n, or \r\n, then this ending had been left in the last header value.
Created commit ed25ae562 in eds master (3.27.92+) Created commit 6ed82836c in eds gnome-3-26 (3.26.6+)
And also when the headers end at the boundary of the chunks being read (4096, 8192 and so on), then it could truncate the message body and show it empty. Created commit d99273664 in eds master (3.29.1+) Created commit a96acb5d8 in eds gnome-3-28 (3.28.2+)