Problem 1: eM Client hangs onto read file handle after done reading the file to encode into a MIME part for the attachment.
I had the compose window open to create a new e-mail. I added 2 .png files as attachments. I sent the e-mail (with the option to notify in a week of no reply). I could not delete one of the .png files after sending the message. The error was eM Client still had a handle on the file. I had to exit eM Client to release the handle to delete the file, and restart eM Client.
Once eM Client reads a file to encode into a long text string into a MIME part in the body of an e-mail, it no longer needs a handle on the file. The file was read, the MIME encoded part added to the body, and thereafter eM Client should no longer have a handle for reading from the file.
Problem 2: Displaying attachments in preview pane, or when message is opened in its own window.
I do NOT want the preview pane in eM Client to show the image attachments. If I want to see them, I will use the attachment control (button) to open in the default filetype handler. This is changed behavior in v9. Was not present in v8. I’ve attached image files to e-mails before, and the preview window never wasted the space to display them. This is reminiscent of decades ago when I used Outlook Express that showed render-able attachments at the end of the preview of an e-mail. I prefer a professional GUI without glitzy, childish, and superfluous fluff. I found no setting to enable/disable displaying of attachments.
I’m not talking about showing inline images within the body using the “Content-Disposition: inline” header for the MIME part. That hints to the client the images should be displayed while intermixed within the text in the body. I’m talking about attachments using “Content-Disposition: attachment” for the MIME part. That should NOT display the attachments, but instead merely present controls to access them, like buttons you click to select to Open (using whatever is the filetype handler associated to the file’s extension). Inline images are okay in the body if that is where the author put them. Attached files should NOT be in the body, should NOT be displayed by default, the client should only present controls to access them on demand, and not automatically render attachments (non-inline) when displaying the e-mail. Automatic display of attachments has been shown in the past to be a security vulnerability. Just because someone adds a pic to their e-mail doesn’t mean I want it shoved in my face. I don’t want to see attachments unless I choose to view them. For “Content-Disposition: attachment”, the client should NEVER display those attachments, or an option lets the user toggle between auto-display and no-display (as the default).
eM Client should follow the RFCs, like:
https://www.ietf.org/rfc/rfc2183.txt
2.1 The Inline Disposition Type
2.2 The Attachment Disposition Type