Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
2.23.0
-
None
-
Unknown
-
Regression
Description
The patch for CAMEL-12630 introduced the following line for Attachment file names in the MailBinding class.
String fileName = FileUtil.stripPath(part.getFileName());
This code usually makes sense, it strips paths from attachment names. However, if the file name of the attachment contains many non-ASCII characters (more than ASCII characters) the file name provided by the mail is Base64 encoded, e.g.: "=?UTF-8?B?6Kq/5pW0?="
As the / is a valid character in Base64 encoding (but is not a path delimiter there) the stripPath() call on that string will mutilate the filename to "5pW0?=".
A workaround for this issue is to set the Java system property "mail.mime.decodefilename" to "true". In this case the part.getFileName() will decode the filename before stripping paths.
The attached unit test might demonstrate the issue.
I am not sure how this can be fixed in a compatible way. One option would be to perform a MimeUtility.decodeText() call on the file name (if it is not null), which will essentially have the same effect as setting the system property (which means that the attachment filename is decoded before processing it further), but this will be kind of incompatible.
Note: The issue will not occur if there are more ASCII characters than non-ASCII characters in the filename, because in that case the non-ASCII characters will be encoded using quoted printable encoding (which does not include a "/" character), and even if the file name is Base64 encoded it does not necessarily mean that the Base64 encoded filename contains a "/", so you might hardly see that issue in real life.