Describe the bug
When working with a message which has a MIME header that contains an email address with non-ASCII characters in the local part, operations that require a FormatOptions argument incorrectly process the email address if FormatOptions.International is false. Specifically, the local part is being encoded with punycode.
Platform (please complete the following information):
OS: Windows
.NET Framework: .NET 8
MimeKit Version: 4.1.0
To Reproduce
Steps to reproduce the behavior:
Build a MIME message.
For one of the email headers (e.g., From, To, CC, etc.) include an email that has non-ASCII characters in the local part. For example, उदाहरण@example.com
Write the message to a file using the default FormatOptions.
Open the message in a text viewer.
Note that the email provided in step 2 has the local part encoded using punycode. For the provided example, that would be xn--p1b6ci4b4b3a@example.com
Expected behavior
In this scenario, I would expect an exception to be thrown indicating that the message cannot be represented without plain ASCII headers.
Code Snippets
using var message = new MimeMessage();
message.FromFrom.Add(new MailboxAddress("Example", "उद\u093eहरण@example.com"));
// Finish building the MimeMessage
using var fs = new FileStream(filePath)
message.WriteTo(FormatOptions.Default, fs);
Additional context
Based on RFC 5890, RFC 6530, and other related RFCs, only the domain part of an email address can be converted between Unicode and ASCII-only formats. These RFCs do not define a method for converting between a Unicode local part and an ASCII-only local part, leaving such decisions up to implementors. RFC 6530 section 4.3 indicates that a a user with an internationalized email address may have all-ASCII address(es) as well, either through having multiple accounts or aliases, but there is no way for an external system to know of the relationship between those accounts.
Describe the bug When working with a message which has a MIME header that contains an email address with non-ASCII characters in the local part, operations that require a FormatOptions argument incorrectly process the email address if FormatOptions.International is false. Specifically, the local part is being encoded with punycode.
Platform (please complete the following information):
To Reproduce Steps to reproduce the behavior:
उदाहरण@example.com
xn--p1b6ci4b4b3a@example.com
Expected behavior In this scenario, I would expect an exception to be thrown indicating that the message cannot be represented without plain ASCII headers.
Code Snippets
Additional context Based on RFC 5890, RFC 6530, and other related RFCs, only the domain part of an email address can be converted between Unicode and ASCII-only formats. These RFCs do not define a method for converting between a Unicode local part and an ASCII-only local part, leaving such decisions up to implementors. RFC 6530 section 4.3 indicates that a a user with an internationalized email address may have all-ASCII address(es) as well, either through having multiple accounts or aliases, but there is no way for an external system to know of the relationship between those accounts.