Bug : Odd File naming on attachments in sent mail

Hi,
emClient v 9.0.1361

I just sent someone an email with an attachment of a PDF file called receipt_942895.pdf. At the recievers end (BT Webmail client) the attachment has the worng name and cannot be opened. The attachment is showing up as xap8.0 (i.e. name = xap8 and extension = 0). The file is not readable. If I rename the attachment to .pdf then it is readable as a PDF. when I looked at the message headers on the receiving side I saw this for the attachment:

Content-Type: application/pdf; name=receipt_942895.pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=xap8.0

It looks like emClient is setting Content-Disposition to xap8.0 and the webmail client at BT is taking this as the file name rather than the proper name. Given that BT webmail is possibly used by some millions of people I would like to log this as a bug to be looked in to please.

Thanks
Paul

This has already been addressed, and the fix will be in the next release.

Hi, Thanks for that. Can you let me have the threads applicable please? I did do a search before posting but didn’t see anything.

Cheers,
Paul

I could really do with knowing Gary if you have that information? I would like to know what circumstances it is likely to happen so I can avoid them.

As I said, this issue has already been addressed, and the fix will be in the next release.

Please be patient until that is available.

1 Like

And if I need to send out emails with attachments in the meantime my recipients will be stuffed. Not entirely helpful Gary.

If you have current VIP Support on your Pro License, please open a Support Ticket with us.

:pensive:
May as well close the topic I guess

You might try to zip the pdf file and see if that avoids emClient’s bug.

Another option which is probably the best, is to use either Tresorit or Filemail to create a secure link and upload the file. Then send the recipient a link instead of attaching a file.

This issue has already been addressed. The fix will be in the next release.

If you want to send attachments as links, eM Client already has an integrated feature to use cloud storage. Please see our blog entry here.

It doesn’t matter if “This issue has already been addressed.” If the OP needed a solution before the next release, he needs a solution. It is true that emClient offers cloud and link support. It is only less private, less secure and harder to setup than either of the options I recommended. Take a look at Tresorit for example and see what it offers an occasional one off sending of a file that should be private. - For example, free, no sign up, notification of when the file is downloaded. File expiration.

Sometimes, if a person is comfortable with google drive (storing files with an advertising privacy invading company), or Onedrive, or dropbox, and wants to authorize emClient then it can be a good option. Or, they can just drag and drop the file to a site (or internal program), and set some parameters without anyone knowing who they are and no setup process at all.

Sometimes that’s a simpler option.

The eM Client cloud and link setup is very simple to do and secure and only takes a few minutes to do.

Once setup as per @Gary blog cloud link above, you just attach the eg: .zip file to eM Client and after typing recipient and subject etc, click “Send” and choose your cloud drive option in the center.

After you click on your preferred cloud drive, you will see a message “uploading files to cloud” and once completed the email will be sent and appear in your eM Client sent box shortly after as normal.

image

Note:- All cloud uploaded files go into your cloud specific cloud drive in a “eM Client Attachments” folder as in the Google Drive example below, so you know where they are when the email has been send to the recipient. You can then always delete it from your cloud drive if you want to later once you know they have already received the file if you want to eg: Save save space in your cloud drive etc.

image

Note:- The only issue you can have is if your eg: .zip or other file attachments are too large for your mailbox provider even uploading to cloud drives won’t work as in eg: Google Mail attachments that don’t normally allow more than 15MB of file attachment at a time in a single email. So keep any attachments under 15MB with Gmail / Google cloud uploads via email or split them up in smaller attachments if you can. Don’t know about mailbox size attachments in one single email with Dropbox, OneDrive, etc.

Quite so :slight_smile: I got the impression that Gary thought I was being unreasonable asking so I kind of gave up. All I really wanted to know is why it only happens sometimes so I could take steps to avoid whatever it was that was causing it to be triggered. Apparently having that knowlege would require a pro license as “us mere plebs” are not worthy of being informed. Using a cloud service would not be an option for me as the person I am sending it to is 96 and can barely understand an attachment, let alone a link to a cloud copy of a file. I am trying to care for him remotely. It would quite literally blow their mind. What I have had to do is resort to using Gmail webmail for him until the next release - which is a shame. It’s all to easy for someone to say “be patient” but it has pretty serious implications and has left a bit of a sour taste to be honest.

If you have a Pro License with VIP Support, please contact us directly about this by opening a support ticket.

Otherwise, if you are using a Free License, or you have chosen not to use VIP Support, please be patient. This issue has already been resolved and the fix will be in the next public release.

If you want to support her, I suggest a simple free remote support tool. I think Anydesk is probably good. She’ll click on a link, perhaps fill in a number and then you’ll be able to run her computer remotely. I don’t have or use the product, but saw it and thought it was really slick and easy. I use Teamviewer professionally, but it is not easy to do ad-hoc support. Anydesk free appeared very simple and easy for ad-hoc support, but that was a couple years ago.

1 Like

I also like TeamViewer for remote support as works great and have used that with eM Client support peeps before no problem.

1 Like

If you are using Windows, please download an internal build from here that resolves the issue: https://www.emclient.com/dist/v9.0.1549/setup.msi

As this in not yet fully tested, I recommend you make a backup using Menu > Backup before the install.

If you have any issues, please let me know.

1 Like

@Gary ive just tested sending a .pdf with that same file name (receipt_942895.pdf) to test just now with your updated fixed internal EMC V9.0.1549 build as above for Windows and (sent perfectly and came out the same name at the other end) on a stock Windows 10 & 11 21H2 with the current EMC client release V9.0 1361 on Windows 10 & 11. Yes i backed up first, but upgraded with no issues.

The odd thing is that I did the same email to the same person and the second time it went fine. No idea why it did it the first time. That’s the annoyng part. No information on the specific circumstances that cause it so can’t really test as the last time I did it - it was okay. :frowning:

I’m presently on 9.0.599 - should I update to this one?