Question

I’m targeting a .NET application for the international market and need to implement mail sending functionality. I’ve noticed on the MailMessage class there are several options for setting encoding:

• BodyEncoding
• SubjectEncoding
• HeadersEncoding
• To, From address encoding

I have added a drop-down in the app’s config page to choose the mail message encoding.

Is it best practice to set every property on the MailMessage to use this encoding? Will mail servers and clients around the world handle it? Or should only some be set this way?

Answer 1

The short answer would be no.

Now, I am going to elaborate why. Correctly i18n-ed mail message supports these features:

• Internationalized Domain Names (IDNA) support for From and To headers (as well as CC, BCC, Reply-To, etc.)
• Recognizable and safe encoding of Subject and other headers
• Correct body encoding

For the time being, i18n-ed domain names are basic ASCII strings, encoded via Punycode (you can read more about it in RFC 3492, RFC 5891 and RFC 5890). To cut a long story short, you should use IdnMapping class to convert from UTF-16 string to ASCII (which you can do by calling GetAscii() method.

By safe encoding for subject line and other (non-address like) headers, I meant that for the time being, it should still be 7-bit safe, as quite a few old and outdated Mail Transfer Agents does not support 8-bit encodings here. Therefore you can actually support user’s choice here, but if user choses something like ISO-8859-x, KOI-8-x, or Shift-JIS, I would recommend to further encode headers using Quoted Printable or Base64 algorithm, just to make sure. If user choses UTF-8, you can encode headers with UTF-7 as well as QP or B64.

Last but not least, you can and even should support user chosen encoding for e-mail message body. However, if it is 16-bit base (like UCS2 or UTF-16), I would recommend to set the Transfer Encoding to something like Base64.