GNOME Bugzilla – Bug 672129
Content-Disposition header confuses mail parser for text/plain
Last modified: 2015-04-29 19:39:03 UTC
Looking at a patch series submitted with quilt, I noticed that Evolution displays it as an attachment instead of inline. Content-Disposition: inline; filename=drivers-gpu-drm-allow-to-load-edid-firmware.patch Thomas Gleixner responded that is Evolution’s fault [1]. [1] https://lkml.org/lkml/2012/3/15/77
Can you post the Content-Type header from that email please?
(In reply to comment #1) > Can you post the Content-Type header from that email please? There is none.
(In reply to comment #2) > (In reply to comment #1) > > Can you post the Content-Type header from that email please? > > There is none. I am sorry. (Ctrl + g does not continue searching in Evolution in contrast to other GNOME programs.) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I will attach the message also.
Created attachment 209841 [details] Example message This is an example message.
Importing the example message into Evolution 3.2, the message was displayed as a text/plain attachment expanded inline by default, and when I clicked "Save As" the suggested filename was "drivers-gpu-drm-allow-to-load-edid-firmware.patch". Seems to be working properly for me.
(In reply to comment #5) > Importing the example message into Evolution 3.2, the message was displayed as > a text/plain attachment expanded inline by default, What does that mean? Either it is an attachment or not. > and when I clicked "Save As" the suggested filename was > "drivers-gpu-drm-allow-to-load-edid-firmware.patch". > > Seems to be working properly for me. Replying to that message Evolution inserts the following at the beginning of the quote! (As I pointed out in my example message I linked to in my original report.) > Einfaches Textdokument-Anlage > (drivers-gpu-drm-allow-to-load-edid-firmware.patch)
(In reply to comment #6) > What does that mean? Either it is an attachment or not. Yes, it's a text/plain attachment as specified by the Content-Type header.
(In reply to comment #7) > (In reply to comment #6) > > What does that mean? Either it is an attachment or not. > > Yes, it's a text/plain attachment as specified by the Content-Type header. Well as written in comment #6 that is not the main problem I have. For example Mutt is able to reply to such a message that the following line > Einfaches Textdokument-Anlage > (drivers-gpu-drm-allow-to-load-edid-firmware.patch) (translation: »Simple text document attachment (…)«) is not shown and the whole message is treated as a “normal” message.
(In reply to comment #7) > (In reply to comment #6) > > What does that mean? Either it is an attachment or not. > > Yes, it's a text/plain attachment as specified by the Content-Type header. Sorry, probably I am not knowledgeable enough about mail terminology and so on. But where is that specified as an attachment. (I would only speak of attachment if there is a multipart(?) header field.) Other messages without the field `Content-Disposition` field also have the field `Content-Type` and replying works like a charm and no additional lines are added.
It's treated as an attachment because a filename is specified in the Content-Disposition header. This is done so you can save the patch (or whatever the text/plain content) to disk apart from the message itself, using the suggested filename.
I believe this still a defect though at least Evolution 3.8.4. It would be more convenient to both be able to save the content separately from the entire message and still view the plain-text content inline. For instance, with header line: Content-Disposition: inline; filename=some_filename.txt There's no way to be able to see plain-text content without saving the attachment or viewing the message source. The attachment is described as "differences between files attachment (some_filename.txt)" If the headers also contain: Context-Type: plain/text then the attachment is described as "plain text document attachment (some_filename.txt)"
I tried with the test message on current development version, which might be pretty much the same as 3.16.1 in this regard. The content related message headers are these: Content-Disposition: inline; filename=....load-edid-firmware.patch Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit while I think the last one was added by evolution on import. The message is shown as an attachment and replying to it produces an empty body. A workaround is to select porting of the "attachment", to get the body populated. The problem is that either it'll be shown as an attachment (then one will be able to save it) or it'll be shown as a text body, then reply will work as expected. Doing both seems odd to me, but for example Thunderbird shows the message body and offers the save, with the "attachment" not being shown inline (only in the attachment bar below the message body). Thus maybe it makes sense to show the main message part as a text body and add an attachment for it, but not shown inline.
Even it's a very rare case (it definitely is in my mail traffic), I made it work somehow. Created commit 0d62626 in evo master (3.17.2+) Created commit 5a36659 in evo gnome-3-16 (3.16.2+)