SmtpClient (.NET) does not encode mail header in conformance with RFC 2047

Question

I am using .NET SmtpClient to send e-mail where the subject might contain characters outside of the ASCII range. The RFC 2047 defines how e-mail text should be encoded when it contains special characters. Here is an example of a subject in an e-mail header:

Subject: Votre enregistrement numéro 123

This should become, after encoding to ISO-8859-1:

Subject: =?iso-8859-1?Q?Votre=20enregistrement=20num=E9ro=20123?=

where all special characters, including ?, = (and others) and white space, are encoded using the =xx escape sequence.

However, when I look at what SmtpClient produces, I discover that it does not escape the white spaces, which means that the mail client receives this header:

Subject: =?iso-8859-1?Q?Votre enregistrement num=E9ro 123?=

meaning that the encoding is broken with respect to (my reading of) RFC 2047. Some e-mail clients are perfectly happy with this incorrect encoding (most of them, in fact, including Outlook and gmail), but one (wanadoo.fr) displays the header in its raw format. This is not what the user should get to see :-(

Is there any known workaround for this issue?

Answer 1

The problem is that the SMTP sender uses a generic quoted-printable encoder that doesn't know anything about the special mode for headers, so I suspect that there will be no simple workaround.

What I would do is check to see if there are any non-ASCII characters such that the subject will get encoded, and if so replace any spaces with underscores (ASCII 95). This should work because the underscore character should be interpreted as a space by the mail reader but shouldn't get encoded by the naive encoder. Maybe this code will work:

string FixSubject(string subject)
{
    foreach (char ch in subject)
        if (ch > '\x007f')
            return subject.Replace(" ", "_");
    return subject;
}

Another possibility is to set the encoding of your email to Unicode or UTF-8 because that seems to trigger Base64 encoding of headers instead of quoted-printable. Using a different encoder should avoid the bug altogether.