Content Disposition header contains line break for long filenames

I have an issue with creation of Content-Type and Content-Disposition header.
When using the MimeBodyPart#setFilename method we encountered the issue that line break is added in case the filename exceeds the length of 60 characters.
Here is the example:
```
Content-Disposition: attachment;
filename*0="Mailing example 1 - Text containing more than 60
characters."; filename*1=pdf
```

In case there is at least one NON-ASCII character the issue is resolved since the filename gets encoded.
We are having issues with characters like line breaks, commas, and spaces in the header.
Is there a way to encode filename in this way in any case, not depending on the type of characters?
When encoding the filename using the URLEncoder#encode method, the header parameter filename is encoded and the line break is not there, but the filename is also encoded and displayed like that in the mail client.

Currently, we resolved the issue by overriding the values for headers to always be encoded.
The outcome is:
```
Content-Disposition: attachment;
filename*=UTF-8''Mailing%20example%201%20-%20Text%20containing%20more%20than%2060%20characters.pdf

```
Will this behavior be changed in some of the future releases or will the filenames with only ASCII characters stay as plain text without encoding?

Start with the MimeBodyPart#setFilename behavior described in the report and compare the Content-Disposition examples for long ASCII filenames and filenames with non-ASCII or special characters. Define the intended encoding and line-wrapping behavior, then verify that the resulting filename remains usable by mail clients; no source files or tests are identified in the issue.

Written by the indexing model from the issue text.