Affects: \5.2.8.RELEASE
I've encountered the following issue in org.springframework.mail.javamail.MimeMessageHelper#addAttachment(java.lang.String, javax.activation.DataSource):
The attachment filename ist added to the MimeBodyPart after calling MimeUtility.encodeText():
mimeBodyPart.setFileName(MimeUtility.encodeText(attachmentFilename));
For longer filenames with non-ASCII characters like german umlauts, this results in a wrong encoding of the filename.
Example: Filename is:
xxxxxxxxxxxxxxxxx xxxxxäxßxxxxx xxxxxxx.pdf
This get's encoded as:
Content-Type: application/pdf;
name*0="=?UTF-8?Q?xxxxxxxxxxxxxxxxx=5Fxxxxx=C3=A4u=C3=9Fxxxxx=5Fxxx";
name*1="xxxx.pdf?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0="=?UTF-8?Q?xxxxxxxxxxxxxxxxxx=5Fxxxxx=C3=A4x=C3=9Fxxxxx=5Fxxx";
filename*1="xxxx.pdf?="
Please note: - The encoded filename starts with =?UTF-8?Q?, which implies encoding according to RFC-1342 - The encoded filename is splitted into two lines, indicated by the parameter name suffiexes 0 and 1. This implies encoding accroding to RFC-2231.
This mix of encodings is invalid and it leads to a faulty display of attachment filenames in mailclients, most prominently perhaps Microsoft Outlook. Please refer to the javamail FAQ for more details: https://javaee.github.io/javamail/FAQ#encodefilename
Would it be possible to remove the call to MimeUtility.encodeText from this method or make it optional?
(edit: fixed typos)
Comment From: jhoeller
Good point, this is rather outdated. I'm introducing a setEncodeFilenames(boolean) method on MimeMessageHelper for 5.2.9, making this configurable but leaving the current default behavior as true... and considering a default change to false in 5.3.
Comment From: achimbitzer
Thank you for your quick reply!