Content-Transfer-Encoding System.Net.Mail.MailMessage

If you have tried to send an email using the System.Net.Mail.MailMessage class and System.Net.Mail.SmtpClient class, you may have come across the problem described in this blog post.  The recipient may receive a garbled message, in which carriage returns are not recognized and are shown are strange characters instead:

This is a test message.=0D=0ANew line should start here.=0D=0A

However, when opening the mail in Outlook, it may appear fine.  It took me some time to figure out what was happing.  I used the TcpTrace tool for intercepting the actual message being sent.  The message message had the following items in its header:

Content-Transfer-Encoding: quoted-printable

When using the obsolete System.Web.Mail classes, the Content-Transfer-Encoding had been 7bit instead of quoted-printable.  I thought the strange characters might have something to do with the Content-Transfer-Encoding being used, and started playing around with the AlternativeView class to add an alternative view to my message which, hopefully, would display correctly in the recipient’s client.  Unfortunately, adding an AlternativeView leaves the original view in the message as well, and this particular client still tried to read that original view. 

At first, I thought I would have to revert to the old System.Web.Mail client.  I decided to try one more Google search to see if there was a way around this, and found a comment by Stanley Roark, buried on the MSDN Library’s page about the MailMessage class.  This solution worked so well for me that I decided it deserved a blog post in its own right, hoping it would make it easier for people to find this solution.  My version of the code, in which you will have to replace some of the strings with those appropriate for your own message:

MailMessage message = new MailMessage(
    "", "");
message.Subject = "Some Subject";
message.IsBodyHtml = false;
message.Body = null;
using (AlternateView body =
        "Some Message Body",
        message.IsBodyHtml ? "text/html" : null))
    body.TransferEncoding = 
        SmtpClient smtp = new SmtpClient("", 25);
    catch (SmtpException ex)

If you found this post helpful, please click below to “Kick” it:

kick it on


3 Responses to “Content-Transfer-Encoding System.Net.Mail.MailMessage”

  1. Agustin Says:

    Man, I spent lots of hours looking for a solution to the same problem.

    I couldn’t accept Outlook was sending the line breaks in the right way and my application was sending those funny characters (actually like a mocking smile) =0D

    So, what you are doing (please correct me if I’m wrong) is creating a null default view (by not setting a mail.body content) and overriding this null default view with another view you can actually control.

    For the second view you CAN specify the transfer encoding we wanted.

    The default view is overwritten by the second because it has no content.
    But, as soon as so you write something in this default view, the email is transferred as a MULTIPART/ALTERNATIVE email, with both views on it.

    Let me know if you don’t understand something I’m writing or if you have further comments 🙂

    Agustin Garzon.

  2. idevelopdotnet Says:

    Hi Augustin,

    Thanks for the comment and yes, your interpretation of the code is correct. Your explanation adds extra value to my post because it might help people get a better understanding of what is actually happening underneath the covers.

    Like you, I spent hours trying to get rid of those annoying characters. Actually, I needed to send my message to a third party service which could not parse my message with those funny characters in it. That made it a necessity for me to get rid of them. As you mentioned, if you do add the default view, the message will contain both views, but that was something the service couldn’t handle either. That’s why I had to make sure that the message contained only the view over which I had full control!

  3. Tim Says:

    Well done Augustin,

    I also spent hours looking for a solution. Seems the silly things take the longest.

    My mail was coming from a web site and was to be picked up by an automated process that just wanted to parse plain text and put the data into a database. It didn’t want to know about any kind of encoding.

    Thanks for posting this solution!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: