Why is the Content-Type incorrect if attachment is drag and dropped from another mail?
If I compose a new mail and attach a PDF from the hard disk, the sent mail is properly created with:
Content-Type: application/pdf; name="filename.pdf"
If I instead compose a new mail and use drag and drop to attach a PDF from another email attachment, the mail is sent with the following mime header:
Content-Type: application/x-unknown-content-type; name="filename.pdf"
I think this is an error. I was able to reproduce the behaviour on linux (91.8.0) and windows (91.8.1).
Összes válasz (7)
I believe what you are experiencing is the life of an attachment as it encounters an OS. It comes in as an attachment and continues out as an attachment. Thunderbird relies on the OS to assign the proper application type.
I find it hard do believe that both windows and linux should be the cause of the issue. When the attachment is loaded from disc, everything is correct. Just when the attachment comes from and goes back to thunderbird it is broken.
I have just verified that it not only happens with PDF files. XML attachments also get the wrong content-type.
To me, it isn't 'broken', but in a state of transition. Not Thunderbird, but the attachment. Is this causing a problem for you, or is this just curiosity? Many 'problems' reported here have nothing to do with Thunderbird, but with the expansive environment in which Thunderbird lives.
The problem occurred in a workflow with mails that are automatically printed. This worked for most users (those that load the attachment from disk) and failed for others (those that drag-and-drop the attachment from other mails).
The software that prints the mails prints only the "printable" parts, i.e., application/pdf will be printed but application/x-unknown-content-type won't be printed.
I've created a bug report regarding this hoping it will get checked out.
Interim workarounds:
When wanting to use pdf which is an attachment in a received email: Either Save pdf to desktop and then attach using desktop saved file. OR Forward the received email which has attachment OR Forward received email and then edit that email, so it removes all the previous content except the attachment, so it looks like a new Write message.
Thanks for escalating this to a proper bug report, let's see what happens.
I knew about the proposed workarounds; I knew that save to hard disk works, and the others are not feasible in our case. Automated mails are generated by a custom application (order processing) and then the customer orders (the PDFs in question) are dragged into those mails.
Regards and thanks for your help