MimeMessageHelper.addAttachment: configurable encoding of attachment filename

[achimbitzer]

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)

[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.

[achimbitzer]

Thank you for your quick reply!