Thanks, but running without add-ons didn't fix it.

I have spent a couple of hours this morning and have narrowed down the problem to a minimum reproducible set of steps. The problem occurs in the transition from TB 45.8.0 to 52.0, in other words the problem doesn't occur in 45.8.0 but does occur in 52.0.

Proceed as follows, in both 45.8.0 and 52.0:

• Create a brand new TB profile
• Click to configure an account later
• Quit TB
• Open the profile folder
• Make a mimeTypes.rdf file containing (this is a cut down file which demonstrates the problem - with a non-existant mimeTypes.rdf file, as default, the CSV is *not* shown inline in either 45.8.0 or 52.0):

<RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#"
        xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 <RDF:Description RDF:about="urn:mimetype:text/csv"
                  NC:fileExtensions="csv"
                  NC:description="Microsoft Excel Comma Separated Values File"
                  NC:value="text/csv"
                  NC:editable="true">
   <NC:handlerProp RDF:resource="urn:mimetype:handler:text/csv"/>
 </RDF:Description>
 <RDF:Seq RDF:about="urn:schemes:root">
 </RDF:Seq>
 <RDF:Seq RDF:about="urn:mimetypes:root">
   <RDF:li RDF:resource="urn:mimetype:text/csv"/>
 </RDF:Seq>
 <RDF:Description RDF:about="urn:root"
                  NC:en-GB_defaultHandlersVersion="-1" />
 <RDF:Description RDF:about="urn:mimetype:handler:text/csv"
                  NC:alwaysAsk="true"
                  NC:useSystemDefault="true"
                  NC:saveToDisk="false">
   <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:text/csv"/>
 </RDF:Description>
 <RDF:Description RDF:about="urn:schemes">
   <NC:Protocol-Schemes RDF:resource="urn:schemes:root"/>
 </RDF:Description>
 <RDF:Description RDF:about="urn:mimetypes">
   <NC:MIME-types RDF:resource="urn:mimetypes:root"/>
 </RDF:Description>
</RDF:RDF>

• Create a text file anywhere called test.eml containing:

To: <test@example.com>
From: <test@example.com>
Subject: test CSV attachment
Date: Thu, 27 Apr 2017 09:55:58 +0100
Content-Type: multipart/mixed;
	boundary="------------5D27B340E9C850CE2E11E73A"
Content-Language: en-GB
MIME-Version: 1.0

--------------5D27B340E9C850CE2E11E73A
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit

This is the body text


--------------5D27B340E9C850CE2E11E73A
Content-Type: application/octet-stream; name="test.csv"
Content-Transfer-Encoding: base64

RmllbGQxLEZpZWxkMixGaWVsZDMNCjEyMywiYWJjIiw0NTYNCg==

--------------5D27B340E9C850CE2E11E73A--

• Run TB again
• Again click to configure an account later
• Double-click the .eml file and open it in Thunderbird
• Click Cancel then Exit on the Account Wizard

In 45.8.0 you will see the first image. In 52.0 you will see the second. The behaviour of 45.8.0 is much more desirable to me.

I've looked at the changelog for 52.0 but I'm not sure what may have caused this change, or whether it was intended or not. I haven't tried the beta versions between 45.8.0 and 52.0, but hopefully the above is enough for someone to be able to investigate this. I'm happy to open this in bugzilla.mozilla.org if it is seen as a bug.

Yes, for me, the particular CSV attachments that I'm having trouble with in 52 (but which worked in 48) are being sent as Content-Type: application/octet-stream, from an external system over which I have no control.

Thanks for the link. However that page seems to only be about what happens when you double-click an attachment, not control over whether an attachment shows inline or not.

I've tried this with no difference, although to be clear I've done this on a "application/octet-stream" CSV attachment, and I'm not sure if that's what you meant by a "properly-encoded csv file".

I edited the saved test.eml file from the original post, changing application/octet-stream to text/plain. If I open that .eml file in Thunderbird, I can see the CSV inline. I clicked on the attachment and set it to open in Notepad and ticked to do this by default. But this still doesn't make application/octet-stream CSV attachments view inline, which they used to do in v48.

I can't find any existing bug covering this, so I'll open a new one. Thanks for your advice so far.

https://www.iana.org/assignments/media-types/application/octet-stream

That is the detail on application octet stream. As you see doing anything with it is not recommended. This recommendation is based on security issues that could arise if the octet stream were a binary executable (read malware)

Basically the sender is malforming the email.