Compatibility issue with Japanese attachment names

[qlikled]

Hi, sorry for posting a question more than an issue, but I didn't find an official reference forum.

I'm currently facing a compatibility issue after migrating from System.Net.Mail to MimeKit/Mailkit for email delivery. We had a report that messages containing an attachment named ジョブ得受注一覧レポート20180410.xlsx (Japanese characters there) get messed when displayed in Outlook 2010 if the message is sent thru a Postfix server.

Investigating the root cause I found a change in the attachment properties of the email message:

System.Net.Mail
----boundary_1_54992854-63ca-4734-9b4f-ccb1fa9acff0
Content-Type: application/octet-stream;
name="=?utf-8?B?44K444On44OW5b6X5Y+X5rOo5LiA6Kan44Os44Od44O844OIXzIwMTct?=
=?utf-8?B?MTJfMjcueGxzeA==?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment

MimeKit
--=-MjO7V8dAISFuZnGM0E3NCA==
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;
name*0*=utf-8''%E3%82%B8%E3%83%A7%E3%83%96%E5%BE%97%E5%8F%97%E6%B3%A8;
name*1*=%E4%B8%80%E8%A6%A7%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88_2017-12_27.xl;
name*2=sx
Content-Disposition: attachment;
filename*0*=utf-8''%E3%82%B8%E3%83%A7%E3%83%96%E5%BE%97%E5%8F%97%E6%B3%A8;
filename*1*=%E4%B8%80%E8%A6%A7%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88_2017-12_2;
filename*2=7.xlsx
Content-Transfer-Encoding: base64

As you can see the former has a Content-Type header, apparently encoded according to RFC-1342 (Encoded-words), while MailKit uses (correctly) RFC-2183 and has Content-Type and Content-Disposition headers set using Parameter Values to encode the name. The problem is that the version of Outlook does not support Content-Disposition and relies on Content-Type name for display, apparently messing up the name if Parameter Values encoding is used.

My option to solve the situation would be to use Encoded-words for the Content-Type name and stay with Parameter Values for the Content-Disposition. First of all, is this a good idea or is possibly introducing more compatibility issues?

I use BodyBuilder to build the message body, I have tried debugging and searching MailKit source to perform the change in the encoding. After adding the attachment and inspecting the object, the MimeEntity that corresponds to the attachment has

• A Header in the collection Headers that shows Content-Type with the Parameter Value encoded string
• A ContentType property that shows the original string, unencoded, as Name property.

My guess is that I should act on the Header to change that. So is there a way to use a different encoding for the attachment headers? Or can you point me to where the header is produced, so I can check if I can implement a different encoding and construct the MimeEntity for the attachment directly?

Thanks

[jstedfast]

What you can do is iterate over the MimePart.ContentType.Parameters and/or the MimePart.ContentDisposition.Parameters. Each Parameter has a EncodingMethod property that allows you to specify which encoding method to use for that property.

To work with Outlook, I recommend using ParameterEncodingMethod.Rfc2047.

[qlikled]

Thanks @jstedfast, great hint. regards