After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 672129 - Content-Disposition header confuses mail parser for text/plain
Content-Disposition header confuses mail parser for text/plain
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
3.2.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2012-03-15 12:16 UTC by Paul Menzel
Modified: 2015-04-29 19:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example message (37.45 KB, text/plain)
2012-03-15 14:11 UTC, Paul Menzel
Details

Description Paul Menzel 2012-03-15 12:16:11 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
Comment 1 Matthew Barnes 2012-03-15 12:22:02 UTC
Can you post the Content-Type header from that email please?
Comment 2 Paul Menzel 2012-03-15 14:05:26 UTC
(In reply to comment #1)
> Can you post the Content-Type header from that email please?

There is none.
Comment 3 Paul Menzel 2012-03-15 14:10:27 UTC
(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.
Comment 4 Paul Menzel 2012-03-15 14:11:30 UTC
Created attachment 209841 [details]
Example message

This is an example message.
Comment 5 Matthew Barnes 2012-03-15 14:27:49 UTC
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.
Comment 6 Paul Menzel 2012-03-15 14:43:24 UTC
(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)
Comment 7 Matthew Barnes 2012-03-15 14:51:46 UTC
(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.
Comment 8 Paul Menzel 2012-03-15 18:41:08 UTC
(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.
Comment 9 Paul Menzel 2012-03-15 18:48:42 UTC
(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.
Comment 10 Matthew Barnes 2012-03-15 21:23:57 UTC
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.
Comment 11 Joe Perches 2013-11-20 17:40:43 UTC
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)"
Comment 12 Milan Crha 2015-04-29 17:08:37 UTC
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.
Comment 13 Milan Crha 2015-04-29 19:39:03 UTC
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+)