The box for 'Do this for files...' is greyed out when the attachment for which you are trying to set the default application is incorrectly encoded. This is caused at the sender's end, but the usual way to correct it at the receiver's end is to receive an attachment sent from an email that encodes the attachment properly. I have often found that sending an attachment to myself from a gmail or hotmail account (through webmail) works, but it may also work if you send yourself an attachment through an account set up in TB. Once you set the default app, i.e. the box is not greyed out, the association is applied even for future, mis-encoded attachments.

Hmmm. I can open these attachments just fine from the message in the inbox. It's when I forward that message and try to open the attachment in the Forward pane that I have a problem. Why would the message be encoded properly when received by Thunderbird, but not encoded properly when Thunderbird forwards?

To test, I sent 3 attachments from Thunderbird on Linux (.docx, .doc and .xlsx), to a Thunderbird recipient on Linux. Again, all attachments open when the message is opened in the inbox. When I forward the message, I get interesting results.

In the Forward pane, when I right-click/open the .docx file nothing happens at all.

When I right-click/open the .doc file it opens in LibreOffice immediately, no "Open as" dialog.

When I right-click/open the .xlsx file, I get the "You have chosen to open" dialog, but the filename is /tmp/nsmail-45.tmp. The "Do this automatically ..." button is grayed out.

So, the .xlsx attachment is somehow stored as a .tmp at this point whereas the .doc file is stored as nsmail-22.doc is able to be opened.

I don't think this is an encoding issue. I think it has to do with how the Forward function deals with editing attachments and how it names the saved temporary files.

Interestingly, the attachments in the first message I tested prior to my OP were sent from mailx, not Thunderbird. I see that ALL the attachments in that message end up with the .tmp file type, even the .doc attachment.

Is this something I can control or is this just the way it is, too bad?

This raises that delightful question about peoples' expectations. I wouldn't even try to edit an attachment, because as an attachment it doesn't have a distinct identity. I'd save it, edit it, then re-attach it. That means I have full control over what tools I can choose between to do the editing, and I have a copy of the modified attachment for myself.

If I were able to use Thunderbird to edit the attachment in place, then I would know I am working with a temporary, nay virtual, file. I don't know how well other tools will work with this (particularly if they are file oriented) and I don't expect to have any copy of the revised edition apart from might be stored as an attachment in my Sent folder.

Maybe my approach is coloured by my working in a regulated industry (which industries aren't regulated?) where generally knowing issue numbers and keeping track of versions is rather important; so an ad-hoc edit that has no traceability is just too dangerous.

So, I wouldn't have even tried to do what your user wants to do.

If it's a light-hearted forwarding of a joke where none of that above applies, I'd forward it inline where I can edit it within Thunderbird. But, admittedly, that's good only for a limited range of content type.

Here is a fairly common problem: you receive a message with attachments, and everything works properly as far as opening or saving the attachments, as helper applications are defined for all attachment types in Options/Attachments/Incoming, i.e. no greyed out 'Do this ... from now on'.

Then, you forward the message, expecting that the recipient will also encounter no issues with the attachments. But very often the attachments are not visible to the recipient, for reasons that are not obvious. So, it turns out the safest policy is to always save the attachments from the original message, then attach them to the forwarded message like any other attachment, first deleting the files that appear to be attached when you select Forward.

Zenos: the user is a lawyer and the files in question are being sent back and forth to another party for modification and refinement. In his case he'd rather NOT save the document before modifying because a) it takes time and b) it is preferable to not have traces of in-process, possibly confidential legal documents accidentally laying around on the disk.

Zenos/sfhowes: I understand the reasoning behind saving docs first before attaching -- I've never thought to try what this user is doing. However, the problem here is that this user used Thunderbird on Windows before we switched his workstation to Linux in an effort to move away from Microsoft. The Windows Tbird (52.5.0) has no problem with this and the user got used to doing this procedure routinely, and liked it! On Windows all tempfiles have the proper extention: nsmail-1.xlsx, nsmail-2.docx, etc. On Linux some seem to have the proper extension (nsmail-22.doc), most do not (.xslx -> /tmp/nsmail-45.tmp).

As a programmer, I am well aware that users can make use of my programs in unintended way. However, when I upgrade or rewrite the application, I need to consider these novel and ultimately depended upon uses in the new version or else I'm in for an earful of pain.

Unless one of you knows of a way to make the temp files have the same file type as the original file, I suppose there is no solution to this. In that case I'll make a bug report, although I imagine this would not be a high priority. Still, consistent functionality, intended or not, should be maintained among platforms. Otherwise, it will be increasingly difficult to convince users to change from Windows; something NOT in the interest of Mozilla.