Setting the attachment code is invalid

[ROMYIM]

Describe the bug
I use BodyBuilder to set attachment's encoding GB18030.
But the encoding is still utf8.

Platform (please complete the following information):

• OS: Windows, Linux
• .NET Runtime: CoreCLR
• .NET Framework: .Net 8
• MailKit Version: 4.6.0

My Code

var bodyBuilder = new BodyBuilder();
var attachments = bodyBuilder.Attachments;
foreach (var mailAttachment in message.Attachments)
{
  var attachment = new MimePart(MimeTypes.GetMimeType(mailAttachment.FileName))
  {
     Content = new MimeContent(new MemoryStream(mailAttachment.Data.ToByteArray()), ContentEncoding.Base64),
     ContentDisposition = new ContentDisposition(ContentDisposition.Attachment)
   };
   attachment.ContentDisposition.Parameters.Add("GB18030", "filename", mailAttachment.FileName);
   attachment.ContentType.Parameters.Add("GB18030", "name", mailAttachment.FileName);
   attachments.Add(attachment);
}

Mail Content

--_000_87AK7MN26NU4MQQ38KS0LR762desktopjfb66g2_--

--_004_87AK7MN26NU4MQQ38KS0LR762desktopjfb66g2_
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;
	name="=?utf-8?B?5oiR55qE5Lu75Yqh5Yiw5pyf5o+Q6YaSKDE15aSp5YaF77yM5ZCr5b2T5aSp?=
 =?utf-8?Q?).xlsx?="
Content-Description:
	=?utf-8?B?5oiR55qE5Lu75Yqh5Yiw5pyf5o+Q6YaSKDE15aSp5YaF77yM5ZCr5b2T5aSp?=
 =?utf-8?Q?).xlsx?=
Content-Disposition: attachment;
	filename="=?utf-8?B?5oiR55qE5Lu75Yqh5Yiw5pyf5o+Q6YaSKDE15aSp5YaF77yM5ZCr5b2T5aSp?=
 =?utf-8?Q?).xlsx?="; size=11916;
	creation-date="Tue, 28 May 2024 01:58:06 GMT";
	modification-date="Tue, 28 May 2024 01:58:06 GMT"
Content-ID: <244962593FC4C443BE786933606BE7C5@1>
Content-Transfer-Encoding: base64

[ROMYIM]

附件名称测试-1.zip
the entire e-mail is in the zip-file

[jstedfast]

Took a quick look at the code and it looks like you are right - the charset string value is not getting used

[jstedfast]

Can you confirm whether or not your FormatOptions.International value was true when you sent the message?

[ROMYIM]

I set the FormatOptions later, but the char-set is still utf8.

SendMail Code

 mailMessage.Body = bodyBuilder.ToMessageBody();

 var formatOptions = new FormatOptions()
 {
       International = true
  };
        
 await smtpClient.SendAsync(formatOptions, mailMessage, cancellationToken);

[ROMYIM]

Not only attchment's charset but also MimeMessage.Froms' and MimeMessage.Tos' is not in effect.
Both FormatOptions.International and FormatOptions.AllowMixedHeaderCharsets are set to true, the char-set is still utf8

[ROMYIM]

Can you confirm whether or not your FormatOptions.International value was true when you sent the message?

the FormarOptions is Default.

[jstedfast]

The above fixes that I committed yesterday should fix the issue.

For what it's worth, FormatOptions.International is supposed to enable Unicode Email (which it technically still isn't doing after my fix, but it also sounds like that's not what you want). In other words, MimeKit shouldn't be encoding email headers at all when FormatOptions.International is set to true.

[jstedfast]

You can test my fixes by using the latest NuGet package from here: https://www.myget.org/feed/mimekit/package/nuget/MimeKit

[ROMYIM]

Thanks, but it doesn't work!
There is interesting thing that the value is 'gb180130....' but ParseOptions.CharsetEncoding is UTF8Encoding

I am not sure whether the MimeMessage was encoded by ParseOptions.CharsetEncoding when SmtpClient sent the message.

[jstedfast]

ParserOptions.CharsetEncoding is only used for parsing and is the fallback charset in case it encounters unencoded 8bit headers. It's not anything you should be concerned about for this.

[jstedfast]

1 thing I should add, though, is that if you want it to use the =?gb18030?b?...?= style of encoding is that you can do this:

attachment.ContentDisposition.Parameters.Add(new Parameter("GB18030", "filename", mailAttachment.FileName) { EncodingMethod = ParameterEncodingMethod.Rfc2047 });
attachment.ContentType.Parameters.Add(new Parameter("GB18030", "name", mailAttachment.FileName) { EncodingMethod = ParameterEncodingMethod.Rfc2047 });

In general, the default encoding method should be used, but some mail clients only understand the rfc2047 encoding method. I'm not sure if that is important for your usage or not.

[ROMYIM]

Just as you said, some mail clients only understand the rfc2047 encoding method such as outlook 2019 or enterprise wechat client.
Otherwise, there is a bug that the new windows mail client saves the mail and the source code always displays utf8 charset.
In fact, the charset setting with gb18030 is effective. I'm sorry.
Thank your answers and support!