Open Dr4K4n opened 1 year ago
According to RFC 2231 which updates 2047 and explicitly allows using encoding definition in the Content-Disposition header, it is required to inform the client about encoding in parameter value being used through the usage of the *
in the parameter name (see the definition od extended-parameter/extended-initial-name in the grammar), so in this particular case, the header should contain:
filename*==?utf-8?Q?XX...
Also would it be possible to share full header definition for which it fails for you? Thanks
Describe the bug We are using the mail-api to parse incoming emails (MimeMessages), we received a particular email with a PDF attachment. The filename of this attachment is encoded in the Content-Disposition header in a "weird" way. This leads to the following exception
Stacktrace:
After googling I found that the header is encoded in "Q encoding" (https://en.wikipedia.org/wiki/MIME#Difference_between_Q-encoding_and_quoted-printable) It is also mentioned in RFC2047 (https://www.ietf.org/rfc/rfc2047.txt). The method jakarta.mail.internet.MimeUtility.decodeText(String etext) is actually able to parse such strings.
To Reproduce See test cases in attached pull request #688
Expected behavior See test cases in attached pull request #688
Envorinment: