Hello Matteo. As far as I am aware there is no upper limitation on character count on attachments, but I can certainly get this tested for you. Can you provide me an example file name and extension so I can try to replicate the issue in house? Thanks Matteo, have a good one!

Hello kyle,

this is an example of a filename: "lettera partnership Ripartiamo da. Equì - Comune.pdf"

this is what the receiver get: "lettera partnership RipartiamoKˆ]{ HÛÛ][™Kœ"

Let me know.

Thanks!

Regards

Matteo

EDIT: 

I can't reproduce this issue with build 7699. Can I ask which build you are using ? Maybe it's a build not containing the recent UTF-8 issues fixes.

Build 7669. I tried different text encoding in webmail. 

But no one seems work properly

Hi, I would try again after upgrading to build 7699 as since 7619 there were quite some fixes about encodings.

I can't recommend the latest (7719) as it was out yesterday and we didn't tested it yet.

Kind regards.

I'll try to upgrade to a new version. I'm just afraid to upgrade cause there were always some problems after upgrading in the past to newer version.

What is the actually stable version?

We've got a number of encoding issues that have been fixed in the last build like Sebastien pointed out. The next build will have some more. Among them I have also fixed this specific issue. This webmail composition issue also affected Subject, From, To, CC, as well as the attachment name, basically any piece of non-ASCII text embedded in a header field. Since it's a composition issue, this will only affect new emails as it had to do with how the headers were generated in the created messages.

This fix will be in the next build we release.