Just to clarify your issue: Are you saying this problem happens with documents received from one user, or does this happen for all documents received from all users?

Just documents from the one user (but not pdf's which do work), which is makes it so hard to understand. thanks

My guess - and it's just that - is that your handlers.json file in profile may be corrupt. I say that only because prior files no longer load. To test this, please close TB, then rename handlers.json to handlersHOLD.json (although any change will work) and restart TB and then open one of the DOC files. If you see the prompt window to open or save, click open and also click to always do that. Please let me know if it works. If it does, you should then see a new handlers.json file in the profile.

There are others on this forum with more experience and if they see this thread, they may have further info, but what I suggest will do no harm. If the test proves nothing, please be sure to CLOSE TB before renaming the original handlers file back to handlers.json.

Thanks. Seems unlikely given that exactly the same problem occurs when I forward the email to my PC, but with nothing to lose I"ll give it a go when I can get near my wife's PC (Tue-to-Thu she uses the PC all day & evenings for work, next available slot is likely to be Friday pm).

I agree; it makes no sense, but I'm puzzled why prior documents no longer load. My suggestion was a shot in the dark and may be irrelevant.

I renamed the handlers file but it made no difference (cleaned up a duplicate msf at the same time). So now that can be included out of the possible causes.

What I don't know is what saving the attachment to disk and opening it from there does. Is there something in the process of writing it to disk that corrects the header in such a way that the process of subsequently reading it allows it to be interpreted correctly? I tried emailing myself the saved copy and the attachment opened from Thunderbird correctly, so whatever it is sticks. It doesn't help explain why files previously readable are now not. I wonder if there was something in the November updates that changed something? That the existing files stopped working points to the problem being at the receiving and not sending end.

Hard to think of anything that would be so specific in it's effect that it only affects attachments from one user.

Thank you for helping think it through with me. Explaining a problem to somebody I've often found to be a useful way to solve it.

I agree: explaining a problem often produces the solution. This problem seems to originate with the person sending the documents. I suggest letting this go, as there may be no solution. However, if you believe there may be something in your configuration causing the problem, you can install a portable version from https://portableapps.com/apps/interne.../thunderbird_portable and set up just the one account that person sends documents to and, when she sends another one, retrieve it with this copy that has none of your settings and none of your addons. If the document has the same problems, then it's out of your hands; if it opens normally, then there is something in your configuration that may (or may not) be corrected. Good luck.

Yesterday the sender sent a document about a different subject to the previous attachments which don't work and this one did. The one obvious difference being in the name of the document which is a simple single word text. The previous documents had names made up of a mix of alpha chars, numerics, spaces, colons and full stops, all of which are valid but perhaps something in the combination results in a problem. (there is also the possibility that the new document was created or converted from Pages to Word in a different way, but that's difficult to check with a client on the other side of the continent who's not IT inclined). So now we've asked them to simplify their naming convention and see how we go. (why documents that previously opened with the compound names now no longer do would require more resources than the game merits, particularly if the change works.) Thank you for helping us work through this problem together. Talking helps.

It may help to share a few of the names that were causing problems. It's an interesting concept.

here are some examples, with a twist I've just noticed: 1)attachment name = aa nn dd:hh:mm.docx (which won't display) but when attachment is saved the file name becomes saved file name = aa nn dd-hh-mm.docx (which does)

2) attachment name = aa nn dd:hh:mm.docx (which won't display) which becomes saved file name = aa nn dd hh mm.docx (which does)

3) print of extract of text file of email with attachment shows: Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;

name="AA 292 21:1:22.docx"

Content-Disposition: attachment; filename="AA 292 21:1:22.docx" Content-Transfer-Encoding: base64

which when attachment is saved becomes AA 292 21 1 22.docx

ps just re-read allowed characters and colons aren't!

Did a bit more digging into allowable characters and came across this website (there are lots, I just show this one as an example as it mentions Unix, Mac OS Classic & Mac OS X, Microsoft, and MS Word):

https://superuser.com/questions/326103/what-are-invalid-characters-for-a-file-name-under-os-x

The upshot is that in Word the following characters are not allowed for file names: \ / : * ? " < > |

The sender of the documents in question is using MAC Pages so can use a : but we're receiving using MS Word and can't. So when naming documents the KISS principle would seem to apply.