Parameter Value is folded although already continuation is used

[masooh]

Describe the bug When using a long filename in a multipart message this filename should be separated with Continuations, see https://tools.ietf.org/html/rfc2231: 3. Parameter Value Continuations. This is used, but also folding (see https://tools.ietf.org/html/rfc5322#section-3.2.2) is used on top of it. As the goal of the "Parameter Value Continuations" is to avoid white space problems, folding should not be used here.

To Reproduce

Session session = Session.getInstance(System.getProperties());
MimeMessage message = new MimeMessage(session);

MimeMultipart multipart = new MimeMultipart("mixed");
MimeBodyPart bodyPart = new MimeBodyPart();
bodyPart.setFileName("This is an attachment with a really long name - I hope it works like intended.txt");
bodyPart.setText("body-part-1 " + Instant.now());

multipart.addBodyPart(bodyPart);

message.setContent(multipart);
message.saveChanges();

FileOutputStream outputStream = new FileOutputStream(new File("out.txt"));
message.writeTo(outputStream);

Result is:

Date: Tue, 14 Jan 2020 18:17:05 +0100 (CET)
Message-ID: <1347137144.1.1579022225328@DWKA-4GYQH5J>
MIME-Version: 1.0
Content-Type: multipart/mixed; 
    boundary="----=_Part_0_1880587981.1579022225230"

------=_Part_0_1880587981.1579022225230
Content-Type: text/plain; charset=us-ascii; 
    name*0="This is an attachment with a really long name - I hope it
 wo"; name*1="rks like intended.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; 
    filename*0="This is an attachment with a really long name - I hope
 it wo"; filename*1="rks like intended.txt"

body-part-1 2020-01-14T17:17:05.242Z
------=_Part_0_1880587981.1579022225230--

Expected behavior Result should be

Content-Type: text/plain; charset=us-ascii;
    name*0="This is an attachment with a really long name - I hope it wo";
    name*1="rks like intended.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
    filename*0="This is an attachment with a really long name - I hope it wo";
    filename*1="rks like intended.txt"

Desktop (please complete the following information):

• OS: Ubuntu
• Version 18.04.3 LTS

Additional context Used Version Jakarta Mail 1.6.4

[bshannon]

I can see that this doesn't look particularly attractive, but it also seems to function correctly. Have you seen mailers that don't handle this properly?

[eworks-felix-altmann]

yes, it's Outlook 365 ;) We use Redemption to Import a MIME file like the one above into Outlook. Using Outlook converter (olRFC822_Outlook as argument for Import()) results in an attachment named "unknown attachment".

[bshannon]

So doesn't it seem like the bug is in Outlook converter, since it's the one that's not interpreting this valid MIME content properly?

[eworks-felix-altmann]

In the example the fields Name and filename both have a newline in it's value. I don't think that's ok. To me it seems you are actively changing the value of a field by putting a newline in.

[bshannon]

There are existing folding and unfolding rules that allow newline to be inserted and removed transparently.

[eworks-felix-altmann]

I'm sure there are. But I struggle to find the corresponding rules. Can you provide a link? Have you successfully tried this folded fields with other mailers?

[bshannon]

RFC 2822 talks about folding white space in headers.

The headers in your example message above work fine in Thunderbird using the UW IMAP server.

[bshannon]

I spent far too much time working on this and I think I've got a fix for it. Unfortunately, the changes are just too large to consider for this release. I'm going to hold them off for a future release, probably a 2.0.1 release. In the mean time, I've pushed the changes into branch ParameterList-fix-418.