User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce: Saving an attached image (tiff) dragging it directly to a folder on my desktop (Windows 10) Actual results: Thunderbird create a fetchUID.INBOX54788 file in that folder instead of regular Tiff file. If I rename that file with Tiff estension I can open it without problems. Expected results: Saving the image with correct name and extension.

Interesting. You're using an IMAP account, I assume, since "fetch" and "UID" are used in IMAP. Does this happen with add-ons disabled? See Help menu.

Yes, Imap account. I have no add-ons installed. All maintenance tasks done, like compatting and folder repair. Regards Paolo Rossi

Gene, ever seen this?

Does normal save-as for that file work ok? I mean without dragging.

Yes, save as works normally.

I tried under Windows 7, same problem. I tried under MacOS and dragging works normally, no problem. I don't know if it help.

More questions: Does that only happen for images or also other attachments? Does it happen when you start Windows in safe mode? Does it happen for all messages with attached images or just a single or a few messages?

1) Ok.. I try with many other emails with attached file like pdf, docx, xls, jpg, png.. NO problems.. 2) I resend to myself with Outlook an email with the same tiff image previously saved with save-as.. and NOW it works!.. I can drag the attached file without any problem. Maybe ther is something wrong inside the original email. I'll attach a zipped saved email.

Thanks, this clarifies the issue. The problem is that the message doesn't contain any text body, it only contains an image part. These are the headers: From: Amalia <xxx@xxx.com> Content-Type: image/tiff; x-unix-mode=0644; name="foto amalia.tiff" Content-Transfer-Encoding: base64 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Message-Id: <951C7891-0378-41D8-B322-26EDCFB6FDB4@kurkchieva.com> Date: Tue, 24 Oct 2017 09:35:49 +0200 To: Paolo <yyy@yyy.eu> Content-Disposition: inline; filename="foto amalia.tiff" X-Mailer: Apple Mail (2.3273) TU0AKgACRKSAP+BACCQWDQeEQmFQuGQ2HQ+IRGJROKRWLReMRmNRuOR2PR+QSGRSOSSWTSeUSmVS uWS2XQuBP+XzOaTWbTecTmdTueT2fT+gUGhUOTTGiUekUmlUumU2nU+oVGpVOOUaqVesVmtVuuV2 ... In this case TB doesn't use the filename when dragging the file out onto the desktop. Alfred, care to take a look where in MIME that problem is caused?

BTW, I noticed those wrong file names when working on bug 1361422.

Jorg K (GMT+2) from comment #10) > Alfred, care to take a look where in MIME that problem is caused? In a normal multipart message, the name of the attachment is appended here as an addition to the URI: <https://dxr.mozilla.org/comm-central/rev/97bf29612932b32707ddd6838047d364947eca13/mailnews/mime/src/mimemrel.cpp#522> Here, this addition is stored in mAttachmentFileName. <https://dxr.mozilla.org/comm-central/rev/97bf29612932b32707ddd6838047d364947eca13/mailnews/base/util/nsMsgMailNewsUrl.cpp#409> mAttachmentFileName will later be used when saving the file. But this is no multipart message. Therefore, the name was never parsed or stored. And if mAttachmentFileName is't set, the IMAP-Folder+UID is used as filename.

Thanks for the analysis so far. Where does the > And if mAttachmentFileName isn't set, the IMAP-Folder+UID is used as filename. happen? Any chance to get the real filename then? Non-multipart messages a surely also parsed in some way. Can we pick up the filename then?