System.Net.Mail and =?utf-8?B?XXXXX.... Headers

Question

I'm trying to use the code below to send messages via System.Net.Mail and am sometimes getting subjects like '=?utf-8?B?W3AxM25dIEZpbGV...' (trimmed). This is the code that's called:

MailMessage message = new MailMessage()
{
    From = new MailAddress("[email protected]", "Service"),
    BodyEncoding = Encoding.UTF8,
    Body = body,
    IsBodyHtml = true,
    ReplyTo = new MailAddress("[email protected]"),
    SubjectEncoding = Encoding.UTF8
};

foreach (string emailAddress in addresses)
{
    message.To.Add(new MailAddress(emailAddress.Trim(), "Person"));
}

message.Subject = subject;

I'd like to emphasize that this does not happen all of the time.

What am I doing wrong?

Furmenty

Answer 1

When your subject contains characters outside the ASCII range, then the mailing software must encode them (RFC2822 mail does not permit non-ASCII characters in headers). There are two ways to do this:

• Quoted Printable (subject starts with "=?utf-8?Q")
• Base64 (subject starts with "=?utf-8?B")

It appears that the framework has figured that the Base64 encoding is more efficient (=shorter) than the quoted-printable encoding. This makes sense when your subject contains relatively many characters outside the ASCII range.

To answer your question: You're doing nothing wrong. That's how internet mail with non-ASCII characters is supposed to look like. Of course, the software that reads such mail should detect and decode such subject fields.

Prize

This is how raw message looks like, but when you get it in an email client it's wrong. I recently found out there is a bug in .NET which makes subjects encoded with UTF-8 encoding malformed. I've already filed this bug to Microsoft. During the research I found some email clients show raw Base64 string if it's malformed. Unfortunately there is no workaround. Dotnet doesn't allow to encode the subject manually, if you do it, it will recode it introducing new errors. – Nisa

@Harry: I think we just tripped over the same problem - do you have a link to a connect bug and/or a workaround? – Spermatic

The only workaround I found for this is not to use UTF-8 encoding and choose language specific one, like ISO or CP. What I found out it was clearly a bug in .NET itself due to invalid subject encoding. I haven't checked on this with new .NET versions though. AFAIR it was present in .NET 4.5.0, not sure if I tested it with 4.5.1, and 4.5.2. – Nisa

Answer 2

I came across this post when I was debugging an identical problem, and based on my further investigations I can provide an alternate explanation to Andreas's:

The problem may be that your e-mail client software (Outlook 2003, in my case) is incorrectly decoding the subject line. In other words, it's a bug in Outlook, not in .NET or your program.

If you use a subject value like this (the letter "c" repeated 256 times), it displays fine in Outlook:

subject = New String("c"c, 256)

Likewise, if you use a subject like this (the letter "c" repeated 178 times, with a Unicode non-breaking space character appended), it also displays as expected in Outlook:

subject = New String("c"c, 178) + System.Text.Encoding.UTF8.GetChars(New Byte() {194, 160})

However, the following subject displays as "=?utf-8?B"-prepended garbage in Outlook:

subject = New String("c"c, 179) + System.Text.Encoding.UTF8.GetChars(New Byte() {194, 160})

The difference is that this third subject line is 256 bytes when UTF-8-encoded. I assume that Outlook must be truncating the subject line to 255 characters before displaying it... which would be fine except that it is doing this by truncating the encoded string to 255 bytes, which cuts off the encoding terminator ("?="), making it undecodable.

This is a bug in Outlook and not your mail provider or .NET; you can see the full, untruncated UTF-8 encoded subject line in Outlook by right-clicking on the message in your message list and selecting "Options..." from the context menu, then scrolling down in the "Internet Headers" box until you see the line starting with "Subject:".

Contrary to the situation that Andreas suggests, the problem manifests itself not only when there are many non-ASCII characters, but when there is one or more non-ASCII characters and the subject line is long. A workaround might be to use a shorter subject line or to strip out all the non-ASCII characters in your subject.

(This bug was particularly tricky for me to track down because, as above, the problem data included no obvious non-ASCII characters -- just a few non-breaking spaces. These display the same as regular ASCII spaces when you print them out to the console. Moreover, if you change the value of the string variable in the Visual Studio debugger, it silently replaces them with regular spaces.)

Crinite

Brilliant detective work jcl - we had exactly the same problem and your post saved me many hours. If anyone else has this issue, there is a fix that can be applied to Exchange Server 2007, here – Mutter

Answer 3

The answer might be in the rest of the trimmed subject -- the section you provided decodes as "[p13n] File", but is you've any non-ASCII characters in there, then I would expect it to encode as it has

Scholz